Jump to content

Jakarta Transactions

From Alfawiki
Jakarta Transactions (JTA)
Company typeAPI specification
IndustrySoftware, Middleware
PredecessorJava Transaction API
ProductsDistributed transaction management API

The Jakarta Transactions (JTA; previously known as Java Transaction API) serves as a fundamental Jakarta EE API designed to facilitate distributed transaction management across multiple X/Open XA compliant resources within a Java platform. Created through the Java Community Process as JSR 907, JTA offers:

  • control over transaction boundaries
  • an X/Open XA interface enabling resource participation in transactions

X/Open XA architecture

Within the X/Open XA framework, a transaction manager or transaction processing monitor (TP monitor) oversees transactions spanning various resources such as databases and messaging systems. Each resource operates under its own resource manager with a dedicated API, for example, JDBC for relational database access. The TP monitor manages distributed transactions by coordinating these resource managers. Applications interact with the TP monitor to initiate, commit, or rollback transactions and utilize individual resource APIs for communication.

JTA implementation of the X/Open XA architecture

The JTA specification includes classes grouped into two primary Java packages:

  • javax.transaction
  • javax.transaction.xa

Based on the X/Open XA model, JTA defines two distinct APIs for handling transaction boundaries, differentiating between an application server such as an EJB container and application-level components. The interface is intended for use by the application server to oversee transaction management, whereas the interface enables client-side entities like servlets or EJBs to manage transactions directly.

To participate in transaction coordination by the TP monitor, each resource manager must implement the interface. Common resource-specific APIs comprise:

  • JDBC for relational database connectivity
  • JMS for messaging middleware
  • Java EE Connector API for generic Enterprise Information System (EIS) integration

API

The Jakarta Transactions API consists of three main elements: a high-level interface for application-driven transaction demarcation, a high-level transaction manager interface tailored for application servers, and a standardized Java mapping of the X/Open XA protocol utilized by transactional resource managers.

UserTransaction interface

The interface empowers applications to explicitly manage transaction lifecycles programmatically. It is primarily employed by Java clients and EJB components.

Invoking the method initiates a global transaction linked to the current thread, with the Transaction Manager handling this association transparently.

Support for nested transactions is optional; if not supported, invoking UserTransaction.begin while a transaction is already associated with the thread results in a NotSupportedException.

The propagation of transactional context across different applications relies on the underlying transaction manager implementation and varies according to specific protocols. For example, implementations based on JTS adhere to the CORBA OTS 1.1 standard. This propagation mechanism remains invisible to application code.

@Transactional annotation

The annotation facilitates declarative control over transaction boundaries and is applicable to any Jakarta EE managed bean, including those managed by CDI.

An example demonstrating its use within a request-scoped CDI managed bean:

<syntaxhighlight lang="java"> @RequestScoped public class ExampleBean {

   @Transactional
   public void foo() { // Transaction is active during this method
       // Business logic execution
   } // Transaction commits or rolls back once method execution completes

} </syntaxhighlight>

The transactional behavior can be customized through annotation attributes, closely mirroring the transactional semantics defined in EJB specifications.

@TransactionScoped annotation

The annotation associates a bean's lifecycle with the span of an ongoing transaction.

Illustration within a CDI managed bean that is request-scoped:

<syntaxhighlight lang="java"> @TransactionScoped public class TxScopedBean {

   private int number;
   public int getNumber() { return number; }
   public void setNumber(int number) { this.number = number; }

}

@RequestScoped public class ExampleBean {

   @Inject
   private TxScopedBean txScopedBean;
   @Transactional
   public void foo() {
       txScopedBean.setNumber(1);
   }
   @Transactional
   public void bar() {
       System.out.print(txScopedBean.getNumber());
   }

} </syntaxhighlight>

Since every method invocation operates within its own transaction, distinct instances of TxScopedBean exist for each call. Consequently, invoking foo() followed by bar() outputs 0, because the value assigned in foo() is not preserved when bar() executes.

UserTransaction support in EJB server

EJB containers are required to provide support for the interface when beans use the BEAN option in the annotation, facilitating bean-managed transactions (BMT). EJB components obtain the either through the interface’s method or via injection using @Resource. Direct interaction with the Transaction Manager is not performed by EJB applications; instead, transaction control is managed automatically by the EJB container and server provider according to the Jakarta Enterprise Beans Specification.

Example demonstrating usage within a bean-managed transaction:

<syntaxhighlight lang="java"> @Stateless @TransactionManagement(BEAN) public class ExampleBean {

   @Resource
   private UserTransaction utx;
   public void foo() {
       utx.begin();
       // Perform operations
       utx.commit();
   }

} </syntaxhighlight>

Alternatively, can be obtained from :

<syntaxhighlight lang="java"> @Stateless @TransactionManagement(BEAN) public class ExampleBean {

   @Resource
   private SessionContext ctx;
   public void foo() {
       UserTransaction utx = ctx.getUserTransaction();
       utx.begin();
       // Perform operations
       utx.commit();
   }

} </syntaxhighlight>

If @TransactionManagement(BEAN) is not specified, a JTA transaction is automatically initiated upon method entry and committed or rolled back on method exit, making explicit calls to unnecessary except in special scenarios.

UserTransaction support in JNDI

When a JTA implementation is present, the UserTransaction object is generally accessible via java:comp/UserTransaction in JNDI.

See also

External links