Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Atomikos TransactionsEssentials: JTA/XA transaction management outside of Java EE

Atomikos TransactionsEssentials: JTA/XA transaction management outside of Java EE

This item in japanese

Atomikos TransactionsEssentials, a Java-based transaction manager, just released version 3.2. InfoQ spoke with Atomikos CTO Guy Pardon to learn more about this release, and also about TransactionsEssentials and third-party transaction managers in general.

Pardon described the major features of TransactionsEssentials:

  • JTA/XA transaction management - Transaction management and connection pooling are provided
  • No application server required - TransactionsEssentials can be used inside of any Java EE application server, or independent of an application server
  • Open Source - TransactionsEssentials is open source under the Apache license, version 2
  • JDBC/JMS focus - Any XA resource is supported, and built-in resource pooling and message listening are provided for JDBC and JMS
  • Spring and Hibernate integration - Documentation is provided which describes how to integrate with both Spring and Hibernate

Pardon also mentioned that Atomikos ExtremeTransactions was based upon TransactionsEssentials, and builds upon it by adding support for non-XA, compensation-based transactions and providing graphical administrative control panels for use in servlet containers. Atomikos also offers subscription-based support services, and a subscription grants access to the extra features in ExtremeTransactions.

When asked why one would want an external transaction manager, Pardon replied:

Let me turn the question around: why would you want an appserver?

Basically, the appserver has one big major productivity problem (besides being an old dinosaur): you have to deploy a packaged archive. This means that whatever you test before deployment is not complete. This also means that during deployment the risk that something goes wrong is high. This is a huge productivity problem IMHO.

Pardon also went on to say that, in many cases, an application server may not be the best solution for an application - he gave SOA/ESB endpoints as an example, stating that asynchronous JMS message handling and processing via JDBC could be done in a much more lightweight and scalable manner.

When asked about future releases of TransactionsEssentials, Pardon described greater JDBC and JMS connection pooling, OSGi support and JMX transaction administration as major features planned for version 3.3. Pardon also stated that adding JMX for the JDBC data sources and JMS connectors was a goal for version 4.0.

Rate this Article