What does Jta= true actually mean?

[badmitrii]

It's not clear to me to understand what jta=true actually means. I was trying to execute a simple database update operation wrapped into a transaction. I did it twice with jta=true and jta=false and it worked fine in both cases. Honestly, I expected that an exception must have been thrown when I set jta to false, but it didn't. So what does the jta attrubute actually mean?

[andey]

Hi,

If set jta=false to disable transaction commit ... if jta=true, you can never call commit from your code on the connection. If jta=false, you must never use these connections in a JTA transacction managed by the container.  It would be better (safer) to use JTA (either UserTransaction or CMT) and allow JBoss to control the transaction boundaries.

If you must set "jta=false" in your datasource and implement commit logic before before closing the connection, but it isn't generally recommend.

It would be better to use JTA (either UserTransaction or CMT) and allow JBoss to control the transaction boundaries.

The jta setting should only be changed from true for specific use cases, Be aware that this is only recommended in certain use cases. If you are handling all the transactions in your code and if they are read only transactions then only set the  jta to false.

Setting jta=false is necessary for legacy application code which is incompatible with JTA. Such code can usually be identified by its explicit calls to Connection.setAutoCommit(boolean) or Connection.commit() / Connection.rollback().

Setting jta=false for a data source pool of JDBC connections prevents the connections from being enlisted in a transaction. This can be perceived as a performance benefit.

Since non-JTA connections cannot participate in a JTA transaction, when such connections are used in the context of JTA transactions their use should be limited to read-only operations. Setting jta=false for data sources from which connections are used in write operations may result in data inconsistency. Non-JTA connections are left in auto-commit mode regardless of any existing JTA transaction context. Each statement executed (SQL INSERT, UPDATE or DELETE) on such connections is implicitly committed, immediately. In a case where an EJB obtains a connection in the context of a JTA transaction (whether in a CMT REQUIRED method scope or after UserTransaction.begin()) and executes multiple writes, transactional integrity cannot be guaranteed by JBoss. If one or more updates succeed followed by a failure, the work performed by the "transactional" method will be non-atomic (i.e. some updates will have been committed while others have not). Application code becomes responsible for preserving data integrity in such cases. Note that writes using both JTA and non-JTA connections within a transaction are unsafe even if the application code manages the transaction context because commit cannot be performed atomically.

You must be taken to ensure there are no connection leaks present in an application using jta=false as the JCA implementation (IronJacamar) will not be able to track as it would with jta=true.

- You should also be using *jta=true* on your datasource (it is currently set to false). jta=true indicates that the datasource will honor the Java Transaction API and allows better tracking of connections by the JCA implementation.  When datasources are configured with jta=true, the container will enlist the connection in the managed transaction if there is an existing container transaction and will explicitly manipulate autocommit on the connection and call commit/rollback when the container transaction completes. This can cause problems if Hibernate is also attempting to manipulate autocommit and call commit/rollback on the same connection.

The default value of jta is true.

Note:

If You are attempting to execute a commit on a connection which can only be committed by the container (i.e. the connection is from a pool with jta=true and it is not legal for application code to execute commit on such a connection).

If your application *code is not designed* to be *compatible with JTA*, you *will not be able to use* the cached connection manager to track potential connection leaks.

--

Anup

[alon3392]

> if jta=true, you can never call commit from your code on the connection

One can call Connection.commit() and all the other standalone JDBC operations as long as there is no JTA transaction in progress.

See:

WrappedConnection.commit() will first check for active JTA transaction which ends up calling WrappedDataSource.checkTransactionActive(). If there is no active JTA transaction it lets the commit continue.

[johnwright121]

When anyone creates a data source then the jta=true or the XA data source is required.  It is required to make the server configuration and the value of the jta=true is the non-XA data source. I have used this when I was doing the data source program for Apple iPad Support.