Atomikos Forum

HI,

I am using atomikos as JTA transaction manager with Mysql database and infinispan cache.

When i run my performance tests(stress tetst) I observe that more than 50% of the time for my business logic(writing into cache and database) is just taken in waiting on

com.atomikos.icatch.impl.Result.waitForreplies()

This is constituted from

com.atomikos.icatch.impl.CoordinatorImp.commit and
com.atomikos.icatch.impl.CoordinatorImp.prepare

Are these synchronous blocks necessary ?

How can I improve by performance when these wait times are more than thr time for my business logic itself ?

I did a little bit of debugging and was able to get teh follwing details. 

Insteqd of running stress tests i fired a single request and enabled atomikos logging and was able to get the following. Teh sinel requsets performs a single db operation and a cache opertaion within a transaction. And i observer that teh prepare and commit for database(mysql) is very fast.But the prepare and commit phase for infinispan takes a long time (around 25 milliseconds). Is there any configuration i am missing ?





Atomikos registering participants

//MYSQL
1803568 2011-12-08 14:11:32,735 [serviceTaskExecutor-2] INFO  atomikos.println:110  - addParticipant ( XAResourceTransaction: 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:746D5F74737065782D6170702D636F6E7461696E65725F31343935 ) for transaction tm_tspex-app-container_10047000002
1803568 2011-12-08 14:11:32,735 [serviceTaskExecutor-2] INFO  atomikos.println:110  - XAResource.start ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:746D5F74737065782D6170702D636F6E7461696E65725F31343935 , XAResource.TMNOFLAGS ) on resource MAIN-MYSQL-CONNECTION represented by XAResource instance com.mysql.jdbc.jdbc2.optional.JDBC4MysqlXAConnection@68f92ae2
 
 //INFINISPAN
1803580 2011-12-08 14:11:32,747 [serviceTaskExecutor-2] INFO  atomikos.println:110  - addParticipant ( XAResourceTransaction: 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:5472616E73616374696F6E5861416461707465727B6C6F63616C5472616E73616374696F6E3D4C6F63616C5861343936 ) for transaction tm_tspex-app-container_10047000002
1803581 2011-12-08 14:11:32,748 [serviceTaskExecutor-2] INFO  atomikos.println:110  - XAResource.start ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:5472616E73616374696F6E5861416461707465727B6C6F63616C5472616E73616374696F6E3D4C6F63616C5861343936 , XAResource.TMNOFLAGS ) on resource TransactionXaAdapter{localTransaction=LocalXa represented by XAResource instance TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=null} LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=tm_tspex-app-container_10047000002} org.infinispan.transaction.xa.LocalXaTransaction@d61cedbd}
 

//RESPONSE FROM INFINISPAN
 
1803586 2011-12-08 14:11:32,753 [Atomikos:26] INFO  atomikos.println:110  - XAResource.end ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:5472616E73616374696F6E5861416461707465727B6C6F63616C5472616E73616374696F6E3D4C6F63616C5861343936 , XAResource.TMSUCCESS ) on resource TransactionXaAdapter{localTransaction=LocalXa represented by XAResource instance TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=tm_tspex-app-container_10047000002TransactionXaAdapter{localTransaction=LocalXa496} LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=tm_tspex-app-container_10047000002} org.infinispan.transaction.xa.LocalXaTransaction@d61cedbd}
1803591 2011-12-08 14:11:32,758 [Atomikos:26] INFO  atomikos.println:110  - XAResource.prepare ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:5472616E73616374696F6E5861416461707465727B6C6F63616C5472616E73616374696F6E3D4C6F63616C5861343936 ) returning OK on resource TransactionXaAdapter{localTransaction=LocalXa represented by XAResource instance TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=tm_tspex-app-container_10047000002TransactionXaAdapter{localTransaction=LocalXa496} LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=tm_tspex-app-container_10047000002} org.infinispan.transaction.xa.LocalXaTransaction@d61cedbd}
1803606 2011-12-08 14:11:32,773 [Atomikos:26] INFO  atomikos.println:110  - XAResource.commit ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:5472616E73616374696F6E5861416461707465727B6C6F63616C5472616E73616374696F6E3D4C6F63616C5861343936 , false ) on resource TransactionXaAdapter{localTransaction=LocalXa represented by XAResource instance TransactionXaAdapter{localTransaction=LocalXaTransaction{xid=tm_tspex-app-container_10047000002TransactionXaAdapter{localTransaction=LocalXa496} LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=tm_tspex-app-container_10047000002} org.infinispan.transaction.xa.LocalXaTransaction@d61cedbd}
 
 

//RESPONSE FROM MYSQL

1803605 2011-12-08 14:11:32,772 [Atomikos:24] INFO  atomikos.println:110  - XAResource.prepare ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:746D5F74737065782D6170702D636F6E7461696E65725F31343935 ) returning OK on resource MAIN-MYSQL-CONNECTION represented by XAResource instance com.mysql.jdbc.jdbc2.optional.JDBC4MysqlXAConnection@68f92ae2
1803606 2011-12-08 14:11:32,773 [Atomikos:24] INFO  atomikos.println:110  - XAResource.commit ( 746D5F74737065782D6170702D636F6E7461696E65725F3130303437303030303032:746D5F74737065782D6170702D636F6E7461696E65725F31343935 , false ) on resource MAIN-MYSQL-CONNECTION represented by XAResource instance com.mysql.jdbc.jdbc2.optional.JDBC4MysqlXAConnection@68f92ae2

Also another related question i had was where did the Atomikos 24 and Atomikos 26 thread come from ?

i have not given any configuration for pool size . The only configuration i mentioned is on com.atomikos.jdbc.AtomikosDataSourceBean whihc I expect is the MYSQL connection pool size.

Is there explicit pooling i have to mention for database(mysql) and cache(infinispan) ?

Sorry for the correction , based on the above logs its not infinispan, but the prepare of xa complaint mysql which is the last to respond to teh prepare phase .

So i think the waitForReplies is always waiting for mysql to resspond.

Si this performance a know issue ?

I am not aware of any such issues so it is certainly not a known issue.

As to where the threads come from: you are probably using threaded 2PC. I recommend that you disable this by setting

com.atomikos.icatch.threaded_2pc=false

in jta.properties. Too many drivers have problems with threaded commits.

HTH

Actually I tried with a better box with higher CPUs and better disk and mysql performance seemed good (the prepare pahse and commit phase was 10-15 times faster).


i would like to keep  com.atomikos.icatch.threaded_2pc=true , because i feel this gives me real good performance and have not faced any issues till now.

Thanks for ur suggestions.