Transactional Behavior with WildFly Data Source Types

WildFly allows creation of different types of data sources, based on their transactional capabilities. The type of data source you create for your VDB’s sources also dictates if that data source will be participating the distributed transaction or not, irrespective of the transaction scope you selected from above. Here are different types of data sources

  • xa-datasource: Capable of participating in the distributed transaction using XA. This is recommended type be used with any Teiid sources.

  • local-datasource: Does not participate in XA, unless this is the only source that is local-datasource that is participating among other xa-datasources in the current distributed transaction. This technique is called last commit optimization. However, if you have more then one local-datasources participating in a transaction, then the transaction manager will end up with "Could not enlist in transaction on entering meta-aware object!;" exception.

  • no-tx-datasource: Does not participate in distributed transaction at all. In the scope of Teiid command over multiple sources, you can include this type of datasource in the same distributed transaction context, however this source will be it will not be subject to any transactional participation. Any changes done on this source as part of the transaction scope, can not be rolled back. If you have three different sources A, B, C and they are being used in Teiid. Here are some variations on how they behave with different types of data sources. The suffixes "xa", "local", "no-tx" define different type of sources used.

  • A-xa B-xa, C-xa : Can participate in all transactional scopes. No restrictions.

  • A-xa, B-xa, c-local: Can participate in all transactional scopes. Note that there is only one single source is "local". It is assumed that in the Global scope, the third party datasource, other than Teiid Datasource is also XA.

  • A-xa, B-xa, C-no-tx : Can participate in all transactional scopes. Note "C" is not a really bound by any transactional contract. A and B are the only participents in XA transaction.

  • A-xa, B-local, C-no-tx : Can participate in all transactional scopes. Note "C" is not a really bound by any transactional contract, and there is only single "local" source.

  • If any two or more sources are "local" : They can only participate in Command mode with "autoCommitTxn=OFF". Otherwise will end with exception as "Could not enlist in transaction on entering meta-aware object!;" exception, as it is not possible to do a XA transaction with "local" datasources.

  • A-no-tx, B-no-tx, C-no-tx : Can participate in all transaction scopes, but none of the sources will be bound by transactional terms. This is equivalent to not using transactions or setting Command mode with "autoCommitTxn=OFF".

To create XA data source, look in the WildFly "doc" directory for example templates, or use the "admin-console" to create the XA data sources.

If your datasource is not XA, and not the only local source and can not use "no-tx", then you can look into extending the source to implement the compensating XA implementation. i.e. define your own resource manager for your source and manage the transaction the way you want it to behave. Note that this could be complicated if not impossible if your source natively does not support distributed XA protocol. In summay

  • Use XA datasource if possible

  • Use no-tx datasource if applicable

  • Use autoCommitTxn = OFF, and let go distributed transactions, though not recommended

  • Write a compensating XA based implementation.

Table 1. Teiid Transaction Participation
Tx-Scope XA source Local Source No-Tx Source

Local (Auto-commit=false)

always

Only If Single Source

never

Global

always

Only If Single Source

never

Auto-commit=true, AutoCommitTxn=ON, or DETECT and txn started

always

Only If Single Source

never

Auto-commit=true, AutoCommitTxn=OFF

never

never

never

results matching ""

    No results matching ""