[XA Datasources]JDBC Clients Design

[gimantha]

Hi all,
As per the current DB client design, we use the same DB client implementation for XA transactions and non-XA transactions. Currently we determine the type of the connection (XA or non-XA) by looking at the datasource we provide. If the datasource is XA, then we try to create a XA connection internally, otherwise we create non-XA connection from the datasource provided.
When we create a XA connection, we have to pass XA properties, that user provides. In our current implementation, in the constructor, we have a nillable parameter called options. We use this to pass XA properties as well as usual other properties like, timeout, parameters related to creating SSL connections.. etc. From the implementation level, there is no way to distinguish the difference between these properties. Also these properties vary from one database to another database. XA properties are something that user has to provide always. So starting this discussion to consider the possible solutions to properly pass the XA properties to the DB clients. @hasithaa @daneshk @niveathika @lafernando @anupama-pathirage

[lafernando]

Yes, this should be just be done in a way that, we should be able to provide a DataSource [1] implementation if required. So when there are specialized data source implementations done by vendors, users can use it - so it's not just for the XA data source case. So when users provide an external data source class like this, we can internally check if it's actually an XADataSource [2] and switch to using it in a distributed transaction by using it with a XA transaction manager. And then, after providing this external data source, there should be a map of properties used to initialize the properties (Java bean) of that instance. These properties shouldn't be mixed with other properties of the client. And when using an external data source, we cannot have other mandatory parameters for a JDBC URL, username, and password separately, since these types of values should be passed directly as data source properties - where its property names would be implementation specific.

The above scenario is of course for the general JDBC client. For DBMS specific clients, they can have their own set of pre-known properties to provide the values and have a field like "isXA" to say if we need to use its XA data source or not.

[1] https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html
[2] https://docs.oracle.com/javase/7/docs/api/javax/sql/XADataSource.html