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.
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.