Atomikos has released TransactionsJTA 1.30, a Java Transaction API (JTA and XA, not JTS) transaction manager with many added and improved features.

Features

• A transactioning micro-kernel very compact yet very powerful
• Distributed transactions across almost any type of resource
• Extremely fast JTA: XA transactions at local transaction performance
• Nested transactions for increased fault-tolerance and server autonomy
• Two-phase commit with extensive heuristic support for increased autonomy
• Read-only optimization for increased performance
• Decentralized design, for perfect scalability and peer-to-peer transactioning
• JTA compatibility
• JDBC support
• JMS support
• Synchronization callback support
• Distributed recovery included

TransactionsJTA is co-shipped for evaluation with:

FirstSQL/J Enterprise v2.70, Featuring J2EE support:
- JDBC and JCA support
- XA/JTA (XADataSource) support
- support for recovery, and more.


Read more about Atomikos TransactionsJTA

<site:buyonline>[$3025] TransactionsJTA, Enterprise (up to 20 concurrent transactions) </site:buyonline>

Who would pay $3025 for an implementation of JTA if u can have it for free with JBoss?

Nelson

Are all JTA's created equal?

Dion

Who would pay $3025 for an implementation of JTA if u can have it for free with JBoss?

It's about reliability, availabity, scalability and performance. When things are going well, and with light load, almost any JTA implementation will do. When things don't go well, and when the load is heavy, that's when you find out if you made the correct choice for a transaction manager. Having tested neither JBoss nor Atomikos as a transaction manager, I'm not suggesting any conclusions, but spending $3000 per CPU for a good transaction manager won't sound bad after you lose a few important transactions, or (assuming that you have foresight) if you think you might in the future. (BTW, one thing that I do remember from an earlier conversation is that the JBoss transaction manager is not even recoverable, so I don't believe that it would qualify as a transaction manager for any serious application.)

It is the same reason why people pay for Oracle, DB2, and Sybase / Microsoft SQL Server: these products are well trusted to take care of data. Same reason why EMC and Veritas and BEA and IBM still sell a lot of stuff: There are companies that depend on their data being treated with care, and they are willing to spend money to see it done correctly.

OTOH Most applications (95% or more, maybe 99% or more) don't even need a transaction manager, so $1 would be too much to spend in most cases, since it's not needed.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

<OTOH Most applications (95% or more, maybe 99% or more) don't even need a transaction manager, so $1 would be too much to spend in most cases, since it's not needed.Peace,Cameron Purdy

I think that's a little strong and perhaps might mislead some folks.

If your intention is to interact with more than one resource manager in a unit of work and you have strong requirements for data consistency, then you're probably going to use global transactions. I wouldn't hazard a guess as to what percentage of applications that represents, but it's probably not negligable.

Greg

I think that's a little strong and perhaps might mislead some folks.If your intention is to interact with more than one resource manager in a unit of work and you have strong requirements for data consistency, then you're probably going to use global transactions. I wouldn't hazard a guess as to what percentage of applications that represents, but it's probably not negligable.

I am a bit confused about your usage of global transaction term. Usually global XA transaction assumes context propagation (more then one TM involved in transaction). That is indeed rather rare scenario and probably should be avoided if possible because it is simply too heavy. (Keep in mind that single TM handle many resources local and distributed alike...)

Regards,
Nikita Ivanov
xTier – Service Oriented Middleware

I am a bit confused about your usage of global transaction term. Usually global XA transaction assumes context propagation (more then one TM involved in transaction)

here is the definition of Global transaction in X/Open world.

========X/Open distributed transaction processing model===========
Global transactions
-------------------
These transactions involve RMs that are defined to the TM, and are under the TM's two-phase commit control. A global transaction is a unit of work that could involve one or more RMs. A transaction branch is the part of work between a TM and an RM that supports the global transaction. A global transaction could have multiple transaction branches when multiple RMs are accessed through one or more application processes that are coordinated by the TM.

Loosely coupled global transactions exist when each of a number of application processes accesses the RMs as if they are in a separate global transaction, but those applications are under the coordination of the TM. Each application process will have its own transaction branch within an RM. When a commit or rollback is requested by any one of the APs, TM, or RMs, the transaction branches are completed altogether. It is the application's responsibility to ensure that resource deadlock does not occur among the branches. (Note that the transaction coordination performed by the DB2 transaction manager for applications prepared with the SYNCPOINT(TWOPHASE) option is roughly equivalent to these loosely coupled global transactions.

Tightly coupled global transactions exist when multiple application processes take turns to do work under the same transaction branch in an RM. To the RM, the two application processes are a single entity. The RM must ensure that resource deadlock does not occur within the transaction branch.

Hi Talip,
Thanks for correction. Let me reiterate my point again: XA transactions involving more then one TM with required tx context propagation is usually overkill and can be (should be) in most cases designed around.

Regards,
Nikita Ivanov
xTier – Service Oriented Middleware

<blockquoteI am a bit confused about your usage of global transaction term. Usually global XA transaction assumes context propagation (more then one TM involved in transaction). That is indeed rather rare scenario and probably should be avoided if possible because it is simply too heavy. (Keep in mind that single TM handle many resources local and distributed alike...)Regards,Nikita IvanovxTier – Service Oriented MiddlewareI guess there's enough precise but overlapping terminology in the transaction space to make it nearly impossible to be precise without a frame of reference.... I meant to suggest a transaction model that involved more than a single branch (as per XA).

Greg

Greg: If your intention is to interact with more than one resource manager in a unit of work and you have strong requirements for data consistency, then you're probably going to use global transactions. I wouldn't hazard a guess as to what percentage of applications that represents, but it's probably not negligable.

Isn't that what I said ;-)

(Yes, your explanation is much clearer / better.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

<OTOH Most applications (95% or more, maybe 99% or more) don't even need a transaction manager, so $1 would be too much to spend in most cases, since it's not needed.Peace,Cameron Purdy

I think that's a little strong and perhaps might mislead some folks.If your intention is to interact with more than one resource manager in a unit of work and you have strong requirements for data consistency, then you're probably going to use global transactions. I wouldn't hazard a guess as to what percentage of applications that represents, but it's probably not negligable.Greg

It's certainly not negiligible and to throw figures like "95%" or "99%" around does a disservice to financial institutions, aviation, telcos, medical, and even (believe it or not) the military. It's an important fault-tolerance technique, but like everything (including J2EE application servers), it has to be used in the right place at the right time. I certainly wouldn't say that transactions are for every application domain, but in some domains the requirement for transactions is significant (and would represent a significant percentage).

Mark: I certainly wouldn't say that transactions are for every application domain, but in some domains the requirement for transactions is significant (and would represent a significant percentage).

Transactions, yes. But (AFAIK) you don't need a transaction manager until you have multiple transactional resource managers, for example transactions that bridge multiple databases.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Mark: I certainly wouldn't say that transactions are for every application domain, but in some domains the requirement for transactions is significant (and would represent a significant percentage).Transactions, yes. But (AFAIK) you don't need a transaction manager until you have multiple transactional resource managers, for example transactions that bridge multiple databases.Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!

It's true that you need the coordination capability in a multi-participant/RM environment (not just distributed). And the examples domains I gave have applications that would fall into that category.

I would agree and disagree with Cameron. I think there is certain amount of functionality in many applications that would require JTA stuff in one way or another. But today, JTA became ubiquitous and expected almost a priory. I believe that commercial JTA TM should come relatively cheap or bundled for free with some inexpensive product edition – that's what we do, for example.

And of course, there is certain functional threshold that any JTA TM should pass to be considered as a serious product. Mike Spill had an interesting stuff recently in his blog regarding JTA.

Regards,
Nikita Ivanov
xTier – Service Oriented Middleware

Atomikos released a real transaction manager module with recovery, guaranteeing automatic restart and crash-recovery. The beauty of it is that you can also connect to multiple Oracle, DB2, Sybase etc. over the Internet.
True that it's a niche market and that most of the applications don't need a Transaction manager, but in some lines of business it's critical (stock exchange, healthcare etc.)

BTW, TransactionsJTA developer license is free!
regards,
Joel.

I don't want to get into a game of license price comparisons but keep in mind that the license price is one thing. Here is a reliable JTA with support
included.

For JBoss, the closest comparison would be to also get production
support:

For USD$5000, you get 20 hours of JBoss support. This is a use or lose
it retainer with a 6 month lifetime. Contact us

For USD$10,000, you get 50 hours of JBoss support. This is a use or
lose it retainer with a 1 year lifetime. Contact us

So in a way, professional installations of JBoss are even more
expensive and much less reliable for data integrity.
If you have high-value transactions or high-value data, JBoss or other
open source is just not an option.

If you have high-value transactions or high-value data, JBoss or other
open source is just not an option.

The problem has nothing to do with "open source", and JBoss being open source has nothing to do with it. Open source does have some very high quality / highly reliable components and libraries. It's just that the transaction management support in JBoss does not qualify yet.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

I agree with Cameron. The issue is not on Open Source 'quality/reliability' but on the criteria used for evaluating a 'real' transaction management tool. And,indeed,JBoss does not qualify yet.

I don't want to get into a game of license price comparisons but keep in mind that the license price is one thing. Here is a reliable JTA with supportincluded.For JBoss, the closest comparison would be to also get productionsupport:For USD$5000, you get 20 hours of JBoss support. This is a use or loseit retainer with a 6 month lifetime. Contact usFor USD$10,000, you get 50 hours of JBoss support. This is a use orlose it retainer with a 1 year lifetime. Contact usSo in a way, professional installations of JBoss are even moreexpensive and much less reliable for data integrity.If you have high-value transactions or high-value data, JBoss or otheropen source is just not an option.

You could also go the tried and tested Arjuna+JBoss route, where you get the Arjuna Transaction Service (ex-HP Transaction Service and the first "micro-kernel" TM).

Mark.

Hi,

Another reason to use JTA is for the Data Access Object (DAO) pattern.

As most of us know, this pattern is about encapsulating all JDBC inside a method on the DAO.
Without a JTA, this means you must also delimit the transactions and make them method-scoped in the DAO. Essentially, this means you can't rollback across multiple DAO method invocations.

With a JTA, you can.

So this brings a JTA well within the scope of more than 1% of the J2EE projects I guess.
As to whether it's mission-critical or not, that obviously depends on each individual case.

Guy

What you have described is an interface polution issue. You can use combination of ThreadLocal and AOP to handle this scenario.