Distributed transactions are generally no good for performance. Can you change your use cases in a way you don't need two phase commits anymore?

First of all I should thank you for your attention. I hope I could describe my situations properly! Unfortunately I should use distributed  transaction and I hope you have a strong reasons about your opinion because many J2EE facilities like JMS, JCA, EJB uses this concept in J2EE. Please show me your references about it.

it's based on my own experience and a dude from Oracle team. However, it's not hard to picture the downright performance impacts of two phase commits. As for changing use cases I am talking more about changing your design in way you could do the same thing with single commits. For example, in a project  I had the mandate to put a data in two databases each of which on an individual data source. One was live data and the other one was historical data good for book keeping and similar. That specific code point would be called a few hundred times in a second and two phase commit was not an option for me. Therefore, I had to register with the present transaction  manager and do the history part at the end of the first transaction and since I didn't want to lock things up for long a JMS queue was used. However, there was a chance that JMS would fail and the only remedy at the time was to dump the data in a local file which would be picked by a system health service later. My assumption at the time was that one of these would work, and if all failed I would be probably one of the guys in WTC buildings on 9/11.

In any events, there are small things that you can do to improve performance. For example, in the same project we opted to disable persistent transactions, and in our scenario it was an improvement. We also decided nested transactions are not for us and that made some performance difference too but to a smaller extent. Splitting logic into transactional units and non-transactional units also helped a lot but this should be done with extreme care.

In addition, I do agree with you that JTA has been smeared all over other J2EE services but at the same time many of these things work  great for vanilla applications. Crossing the vanilla line requires a little bit of thinkering here and there.

I see your point and I do accept that 2PC can be one of major bottlenecks in a system. In fact I see that these-days the world is trying its best to eliminate the need to XA by various other techniques. Meanwhile there are occasions that 2PC is the (only) answer and any other attempt would risk correctness.

Then we came to Soheil's question. Well, first of all I definitely reject JOTM. It _was_ a good movement one day but I don't see any active development/bug-fixes anymore. There are various bugs either with JOTM itself or with its bounded pooling systems; XAPool.

I have done some benchmarks on some other open-source and commercial transaction  managers. It is very hard to say which one is better since in fact there is not much thing to be done inside of transaction-manager. The most important factor, for sure is the driver itself. The way XA driver works with your resource and the amount of IQ it has is the main player.

Then we came to manager  itself. IMO main points a TM should handle are 1) Heuristic decisions 2) Disk-force 3) Statement pooling; and these elements results in minor differences in TPS. Disk force for example has its impact either on performance or journaling. One you enforce sync disk journaling you will lose perfomance a will but will gain greater crash-recovery in return.

IMHO I would recommend these TMs: 1) Bitronix 2) AtomikosTE 3) WebLogicTM 4) JBossTS. It's hard to believe but for me BTM does the best. It's a small and handy manager but does its job very well. WLS is cool but your are somehow bound to BEA. Atomikos is also a good alternative if you censored about recovery.

2 cents again and I will try to publish my benchmarks if I find a few minutes of spare time

I've used BEA JTA transaction  management and it worked very well in high load.
I'm not sure wethere Tomcat suppotrs JTA or not. but if so it does,I suggest you to put the task on app. server.Then you have better management on critical conditions.