JTA for Tc Server?

[cesnek]

Hi,
I am curious if there is any recommended JTA provider for TC Server.

We tested JOTM+XAPool and Atomikos with very very bad results.



Is there official recomended guidance?

Or this is completely left to Spring itself?


Is there anyone who successfully replaced old JOTM with something else?

Has anyone tried c3p0 with Geronimo JTA?

[Andy Wilkinson]

We're currently working on our own JTA implementation that will be available as an add-on for or included in future versions of tc Server and dm Server.

Our transaction manager will integrate with the high-performance connection pool that's part of tc Server.

Expect to see some more official announcements and details around the details of JTA support around the time of SpringOne next month.

[cesnek]

Thank you for answer.

Honesty, all we need is to be able to connect more than one database.

Now we use JtaTransactionManager for this. Even though we dont need 2PC commits and database recovery. I looking forward for BestEffort transaction manager to be included in Spring core.

[GuyPardon]

Hi,

I am from Atomikos. For reasons explained here you can't combine C3P0 with our (or any other) JTA:

http://www.atomikos.com/Documentatio...ConnectionPool

That being said, we work hard to make our pools the best we can - and our 3.5 release should be well-suited in that respect.

AFAIK SpringSource has always recommended against any JTA. Other popular open source products, like Hibernate, are actually pro-JTA.

Based on our own experiences (and those of many of our users), Spring JMS/JDBC applications are far better off with JTA - however if there is any way things can improve then we'd be glad to hear... What are those serious problems you have encountered?

Best
Guy

[Andy Wilkinson]

Honesty, all we need is to be able to connect more than one database.

Now we use JtaTransactionManager for this. Even though we dont need 2PC commits and database recovery.

If you haven't already seen it, you may be interested in Dave Syer's article on approaches to transaction management, both with and without XA.

If you want to connect to multiple databases, but you don't need or want two-phase commit, then you'll either be looking at using a transaction manager with good support for a one-phase commit optimisation, but this would rely on the first of your resources consistently voting read-only, or adopting a best-effort 1PC approach, which will require some additional code in your application to cope with cases where things do go wrong.

AFAIK SpringSource has always recommended against any JTA. Other popular open source products, like Hibernate, are actually pro-JTA.

The opinions and approaches outlined in Dave's article that I've linked to above are a good representation of how Dave and I at least (I can't speak for everyone in the company) see JTA. There is a small class of applications for which a transaction manager and 2PC is essential, where it makes absolute sense to pay the performance cost of two-phase commit. What we recommend against is the blanket usage whenever two resources are involved in a transaction as, sometimes, it makes no sense as the performance cost greatly outweighs the benefits.

[GuyPardon]

What we recommend against is the blanket usage whenever two resources are involved in a transaction as, sometimes, it makes no sense as the performance cost greatly outweighs the benefits.

I agree, but then again I also prefer to try the 'real' solution first and dismiss that for tweaks or hacks _only_if_needed. In my career have seen many designs get cluttered just because of 'perceived' performance problems (that turned out to be non-issues in the end) - and I am not merely talking about XA or transactions in that case.

My point is that performance-based arguments are the very last ones to try, after the preferred and more elegant solution/design has been tried and proven inappropriate.

Other than that, we do care a lot (at Atomikos) about improving all we can, so if you have any concrete suggestions for reducing our logging overhead then we'd be more than glad to listen.

Cheers
Guy

[GuyPardon]

It's fairly easy to do this:

3rd party pools _can_ integrate with Atomikos very easily provided that these conditions hold:

-the pool is XA-aware
-the pool is JTA-aware and uses the JTA api to enlist in a transaction
-(optional but recommended): the pool uses the Atomikos API to trigger recovery at startup time

AFAIK c3p0 does not do this (I could be wrong) nor does any other decent pool I know of...

We did this for the JBoss pools at the time. The same thing should be easy to do for tcServer.

Guy

[tosehee]

IMO, these servers should have either

1) Pluggable architecture for an enterprise level transaction management
2) Come bundled with #1.

When we make a decision to buy or stick to these servers, we are not buying just for a current needs. We might have only one database which warrants only one session factory. However, as soon as the need rises, we dump spring source, and get the appserver that does support this?

I mean for tcserver to be competitive, these things need to be there. Whether jta is required or not, that's per customer's need and decision, not spring source's.

Just my $0.02.

[aaron.cunningham]

We were told by one of the SpringSource employees on a recent ticket we filed to use Atomikos with JTA. I have to say we thought it was going to be a large task switching everything up given that our current apps were wired up in the Spring config files to use Websphere JTA. To our amazement, we literally put the atomikos and transaction jars in our common/lib directory and changing the class names in the config files and everything worked without any tweaking.

Great job Atomikos!

[tosehee]

We were told by one of the SpringSource employees on a recent ticket we filed to use Atomikos with JTA. I have to say we thought it was going to be a large task switching everything up given that our current apps were wired up in the Spring config files to use Websphere JTA. To our amazement, we literally put the atomikos and transaction jars in our common/lib directory and changing the class names in the config files and everything worked without any tweaking.

Great job Atomikos!

That's one of the solution. I also tried that route with a great success until I realize that we are using the mysql as our db, and it lacks the XA_JOIN feature which pretty much puts this entire 2PC on hold..

I am glad that you found a solution to your problem though.