The JTA is the specification that established the APIs of the transaction manager and the way of which it should interact with the other components involved in a distributed transaction system:

• The application
• The resource manager
• The application server

As I explained earlier, you are able to use these APIs in a container-managed way, also known as a declarative model, or in a bean-managed way, also known as a programmatic model. The recommended way of managing transactions is by the container that handles all the phases of the transaction life cycle. From my experience, managing transactions programmatically is only necessary in very exceptional use cases and needs a deep knowledge of transactions, concurrency, and recovery strategies.

In the first case (the declarative model), the developers usually ask the container to manage the transactions through the use of EJB.

Many consider EJB a complex and not very scalable technology. Personally, I do not agree with this assessment, which is based on a negative prejudice that has developed in relation to version 2 of this technology. From version 3.0 on, the use of EJB has been greatly simplified; their configuration, as well as their use, is not very different from that of the beans present in the Spring framework.

However, for those that do not want to be tied to the EJB context, two new annotations, @Transactional and @TransactionScoped, were introduced in version 1.2 of the JTA. These annotations enable simple managed beans to behave as an EJB but without any dependencies on the EJB container. They also provide feature that enables the developers to specify a standard CDI scope for the bean instances, whose life cycles are related to the currently active JTA transaction. We used them in the microservices examples we implemented in Chapter 4, Building Microservices Using Thorntail.

When the transaction manager works in JTA mode, the data is shared in the memory, and the transaction context is transferred by remote EJB calls.

Regardless of the technology used, developers are required to configure the container, setting how individual transactions should be managed by it. The permitted values are as follows:

• MANDATORY: The execution method of a client must happen inside of a transaction context. If there is a transaction context and the EJB method is executed inside its scope, the container uses it; otherwise, an exception is thrown.
• REQUIRED: The execution method of a client must happen inside of a transaction context. The specification defines that if the transaction context is already present, it must be used; otherwise, a new transaction context will be started by the container. This is the default value for all methods defined in EJB.
• REQUIRES_NEW: The container creates a new transaction context on every method's invocation. If a transaction context is already present, it will be suspended by the container for the duration of the execution of the new transaction.

• NOT_SUPPORTED: The execution of a method happens only outside of a transaction context. If a transaction's context is created before the invocation of the method, it will be suspended and then the method will be invoked. Otherwise, the method will be executed without the creation of a new transaction context.
• SUPPORTS: If the execution of a method happens with a transaction context, the container will behave in the same way as the REQUIRED attribute. Otherwise, the behavior of the container will be the same as what we described for the NOT_SUPPORTED attribute.

In the second case (the programmatic model), developers use the javax.transaction.UserTransaction interface to handle the entire transaction life cycle, mainly using the following methods:

• begin(): Start a new transaction, and associate it with the current thread
• commit(): Complete the transaction associated with the current thread
• rollback(): Rollback the transaction associated with the current thread
• setRollbackOnly(): Update the transaction status associated with the current thread so that the only possible result of the transaction is to rollback