This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

We are evaluating between JBoss and Atomikos Transaction managers.
Atomikos - version 3.5.4
JBOSS JTA - version 4.6.1 GA

We have the UT, TM, Spring JTATM, EntityManagerFactory etc all configured based on spring's documentation. The problem I am having right now is with using JBoss JTA.

This is what I have done.
1. I have the driver configured to be jboss's TrasactionalDriver.
2. Since its a standalone j2se application, for jboss to find the XA Datasource, I have implemented the DynamicClass interface. Here I return an instance of net.sourceforge.jtds.jdbcx.JtdsDataSource.
3. I give the name of this class for the DynamicClass property for TransactionalDriver.
Spring configuration looks something like this below.
<!-- Construct JBoss UserTransactionManager, needed to configure Spring -->
<bean id="jbossTransactionManager" class="com.arjuna.ats.internal.jta.transaction.arj unacore.TransactionManagerImple">
</bean>

4. I have set up MS Sql server for XA (all the service packs, MSDTC settings, role/user privelage settings.)
5. I have transactional advices setup so that an "init" method in a DAO class is transactional (read-only actually, since all this does it read some info from the database for server startup purposes.
6. The DAO class has toplink JPA's EntityManager injected into it. It's init method implementation will perform the following against 2 different entities. Something that looks like below.

When I boot up my application, I can see that the DynamicClass implementation is invoked, it connects to the database. But here is the problem. When my DAO bean is initialized, the init method is invoked. The first query above works. The second call, however, throws an exception.

Now, the whole init() method is marked for read-only transaction using a tx-advice. Why does the second call fail with this problem. Shouldnt the same connection/resource used for the second call too. Does JTDSDatasource have problems? Or am I missing some configuration for either JBoss JTA or spring JTATransactionManager wrapper or toplink JPA?

Looks like the problem is with the jtds XA datasource or the configuration for the datasource. I swapped the JTA transaction manager from Jboss Jta to Atomikos. And I get the same error, though, in this case the error is more clear. Instead of the "Cannot enlist resource" SQLException atmoikos's exception clearly says, the transaction id is duplicate.

To remove JTDS from the picture, i now swapped the XA datasource from jtds to microsoft's XA enabled datasource. I am still using Atomikos JTA. Now, the duplicate transaction id problem is gone. However I see a new problem. This seems to be an issue with combination of toplink and atomikos. Atomikos jta logs says something like "waiting for a free connection in the pool" and then times out.

I have set the max connection pool size to be 10, this is in the configuration for AtomikosDatasourceBean. One single call to entityManager.find() on an entity that has a few one-to-many relationships seems to run out of connections (In this case this one entity is mapped to a table with one to many relationships with 4 other tables in the database). From the MS jdbc driver log, I can see that a single JPA calls mulitiple get connections. If i bump up the max connections to the 100s, it seems to work.

Atomikos documentation says that even if the connections are closed in the middle of a transaction, tx manager doesnt release it to the pool till the transaction is commited/completed, which kind of makes sense. But I would think toplink JPA implementation would use the same connection to fetch all the data from all the tables for this one entity, especially when its one single "find" call. Why would it use multiple connections to satisfy one single call. Seems awfully ineffecient, unless there is a configuration that toplink allows to change this behavior.

I will most likely have to post this on the toplink/jpa forums. But if anybody has any pointers for this problem, please let me know.
Thanks