In the X/Open XA architecture, a transaction manager or transaction processing monitor coordinates the transactions across multiple resources such as databases and message queues. Each resource has its own resource manager. The resource manager typically has its own API for manipulating the resource, for example the JDBC API to work with relational databases. In addition, the resource manager allows a TP monitor to coordinate a distributed transaction between its own and other resource managers. Finally, there is the application which communicates with the TP monitor to begin, commit or roll back the transactions. The application also communicates with the individual resources using their own API to modify the resource.
JTA implementation of the X/Open XA architecture
The JTA API consists of classes in two Java packages:
The JTA is modelled on the X/Open XA architecture, but it defines two different APIs for demarcating transaction boundaries. It distinguishes between an application server such as an EJB server and an application component. It provides an interface,, that is used by the application server itself to begin, commit and roll back the transactions. It provides a different interface, the, that is used by general client code such as a servlet or an EJB to manage the transactions. The JTA architecture requires that each resource manager must implement the interface in order to be managed by the TP monitor. As stated previously, each resource will have its own specific API, for instance:
The Jakarta Transactions API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for an application server, and a standard Java mapping of the X/Open XA protocol intended for a transactional resource manager.
UserTransaction interface
The interface provides the application the ability to control transaction boundaries programmatically. This interface may be used by Java client programs or EJB beans. The method starts a global transaction and associates the transaction with the calling thread. The transaction-to-thread association is managed transparently by the Transaction Manager. Support for nested transactions is not required. The UserTransaction.begin method throws the NotSupportedException when the calling thread is already associated with a transaction and the transaction manager implementation does not support nested transactions. Transaction context propagation between application programs is provided by the underlying transaction manager implementations on the client and server machines. The transaction context format used for propagation is protocol dependent and must be negotiated between the client and server hosts. For example, if the transaction manager is an implementation of the JTS specification, it will use the transaction context propagation format as specified in the CORBA OTS 1.1 specification. Transaction propagation is transparent to application programs.
@Transactional annotation
The annotation provides the application the ability to control transaction boundaries declaratively. This annotation can be applied to any class that the Jakarta EE specification defines as a managed bean. The code sample below illustrates the usage of @Transactional in a request scoped CDI managed bean: @RequestScoped public class ExampleBean
Transactional behavior can be configured via an attribute on the annotation. The available options closely mirror those of the EJB specification.
@TransactionScoped annotation
The annotation provides the application the ability to declare that the scope during which a bean lives is tied to the time a given transaction is active. The code sample below illustrates the usage of @TransactionScoped in a request scoped CDI managed bean: @TransactionScoped public class TxScopedBean @RequestScoped public class ExampleBean
If method foo is first called on a managed instance of ExampleBean and then subsequently method bar is called, the number printed will be 0 and not 1. This is because each method had its own transaction and therefore its own instance of TxScopedBean. The number 1 that was set during the call to foo will therefore not be seen during the call to bar.
UserTransaction support in EJB server
servers are required to support the UserTransaction interface for use by EJB beans with the BEAN value in the annotation. The UserTransaction interface is exposed to EJB components through either the EJBContext interface using the getUserTransaction method, or directly via injection using the general @Resource annotation. Thus, an EJB application does not interface with the Transaction Manager directly for transaction demarcation; instead, the EJB bean relies on the EJB server to provide support for all of its transaction work as defined in the Jakarta Enterprise Beans Specification. The code sample below illustrates the usage of UserTransaction via bean-managed transactions in an EJB session bean: @Stateless @TransactionManagement public class ExampleBean
Alternatively, the UserTransaction can be obtained from the SessionContext: @Stateless @TransactionManagement public class ExampleBean
Note though that in the example above if the @TransactionManagement annotation is omitted, a JTA transaction is automatically started whenever foo is called and is automatically committed or rolled back when foo is exited. Making use of a UserTransaction is thus not necessary in EJB programming, but might be needed for very specialized code.
UserTransaction support in JNDI
The UserTransaction should be available under java:comp/UserTransaction.
