Java / Java Transactions (JTA)

Java Transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.

The JTA allows applications to perform distributed transactions, that is, transactions that access and update data on two or more networked computer resources.

The Java Transaction 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.

Transaction demarcation always wraps a sequence of actions, such as a single request, a single method, or a section of code within a method. The demarcation initializes some transactional behavior before the demarcated area begins, then ends that transactional behavior when the demarcated area ends. The application server uses these demarcations to determine the appropriate calls to the TransactionManager object.

Declarative Demarcation: When using declarative demarcation, you specify what transaction demarcation modes should be used around certain areas of code. Rather than implementing these demarcations directly in your code, you declare the demarcations in a configuration file or deployment descriptor. The application server is then responsible for making sure that the correct transactional behavior is used around the specified area.

Programmatic Demarcation: At times, you might need to demarcate transactions in your code. Generally, you should use programmatic demarcation as little as possible, as it is error-prone and can interfere with the application server?s own transaction demarcation mechanisms. If you find it necessary to use programmatic demarcation, you must be very careful to ensure that your code handles any unexpected errors and conditions.

When an enterprise bean defines the boundaries of the transaction it is referred as bean-managed transaction. In bean-managed transaction demarcation, the code in the session or message-driven bean explicitly marks the boundaries of the transaction.

Although beans with container-managed transactions require less coding, they have one limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all. If we use bean managed transaction we are responsible for programming transaction logic into your application code so that developers are responsible for issuing a 'begin' statement and either a 'commit' or an 'abort' statement.

The benefit of bean managed transaction is that as a developer you have full control over transactional boundaries. For instance, you can run series of mini transactions within a bean's method using bean managed transaction.

A transaction defines a logical unit of work that either completely succeeds or produces no result at all.

A distributed transaction is simply a transaction that accesses and updates data on two or more networked resources, and therefore must be coordinated among those resources.

• The application,
• application server,
• transaction manager,
• resource adapter,
• and the resource manager.

The resource manager is nothing but a relational database management system (RDBMS), such as Oracle, SQL Server. The actual database management is handled by this component.

The resource adapter is the component that acts as a communications channel, or request translator, between the "outside world,", the application, and the resource manager. A JDBC driver is an example of resource adapter.

Required is the default transaction attribute that ensures the methods are invoked within Java Transaction API transaction context. Required makes the transactional context used by the bean. If not the new context will be created.

RequiredNew is used when the required results of the transactions to be committed irrespective of the caller's transactions.

Use the Mandatory attribute if the enterprise bean?s method must use the transaction of the client.

If the client is running within a transaction and invokes the enterprise bean?s method, the method executes within the client?s transaction. If the client is not associated with a transaction, the container throws the TransactionRequiredException.

• Required,
• RequiresNew,
• Mandatory,
• NotSupported,
• Supports,
• and Never.

JTS is a specification for implementing a Java transaction manager. A transaction manager serves as an intermediary between an application and one or more transaction-capable resource managers such as database servers and messaging systems. The JTS specification encompasses the JTA API specification.

In the X/Open XA architecture, a transaction manager or transaction processing monitor (TP 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 rollback the transactions. The application also communicates with the individual resources using their own API to modify the resource.

The javax.transaction.Transactional annotation provides the application the ability to control transaction boundaries declaratively. This annotation can be applied to any class that the Java EE specification defines as a managed bean (which includes CDI managed beans).

No, the J2EE platform supports only flat transactions.

No. Simply putting a transactional attribute on a method won't help if the resource manager can't use a transactional context.

No. Entity beans always use container-managed transaction demarcation. Session beans can use either container-managed or bean-managed transaction demarcation, but not at the same time.

Global Transaction is an application server managed transaction, allowing to work with different transactional resources (for example, two differences databases, database, and message queue, etc).

Local Transaction is resource specific transaction (for example, Oracle DB Transactions) and application server has nothing to do with it.

Yes.

XA is a two-phase commit protocol that is natively supported by many databases and transaction monitors.

It ensures data integrity by coordinating single transactions accessing multiple relational databases. XA guarantees that transactional updates are committed in all of the participating databases, or are fully rolled back out of all of the databases, reverting to the state prior to the start of the transaction.