Atomikos has published release 2.10 of Transactions, its transaction processing software for Java.

An important new feature in this release is the support for transactional JMS message listeners, meaning that message-driven applications can be developed and run without the need for EJB or an application server. The transaction support avoids message loss and/or duplicate messages. Queue bridging (across JMS domains) is also provided.

When combined with IoC/AOP frameworks like Spring, POJO applications obtain message-driven and transactional services comparable to EJB, but without the requirement for an application server.

Main new features of Transactions 2.10:

• Transactional message listener support
• Queue bridging: bridge messages across queue domains, without message loss or duplicates
• JBoss 4 support
• Console file rotation
• JCA 1.5 inbound transaction support
• Spring support

Ever-green features include:

• 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
• 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, including transactional message listeners and queue bridging
• Synchronization callback support
• RMI (JRMP and IIOP) support
• Distributed recovery included
• J2SE support included
• J2EE support included: integrates with most J2EE platforms

Atomikos Transactions includes DBMS (evaluation software) from FirstSQL: http://www.firstsql.com.

Extremely fast JTA: XA transactions at local transaction performance.

Really? XA requires two disk write forces per Resource Manager (one for xa_prepare and one for xa_commit) plus the disk writes needed by the Transaction Manager itself (when updating its transaction log). Local transactions do not incur the cost of the tranlog nor the prepare disk writes. These disk writes take 5-10ms each depending on the disks you have.

I would be interested to understand how the product has been optimised to eliminate the above latency costs.

Andrew

Really? XA requires two disk write forces per Resource Manager (one for xa_prepare and one for xa_commit) plus the disk writes needed by the Transaction Manager itself (when updating its transaction log).

You are right if you say that more disk I/O may be necessary. But it is possible to tune this, depending on how many resources are involved and what you can do in parallel. Our transaction service is also intra-VM which helps as well.

Local transactions do not incur the cost of the tranlog nor the prepare disk writes.

A commit of an update transaction will always require at least one disk write (even if it is in the DBMS itself). Typically, depending on the DBMS cache management, even rolled back _local_ transactions can sometimes incur disk writes into rollback segments.

In general, our benchmarks showed higher JTA/XA throughput than a typical (web) application server could handle on the same machine.

Guy