Transaction handling is one of the most important elements of an enterprise application.

A transaction is a unit of work that provides an all or nothing property to the operation that is running within its scope. Furthermore, it guarantees that shared resources (for example, database records or messages in a messaging broker) are protected from access by multiple users that try to change them concurrently. The transaction is in a block of inseparable sequences of operation—to guarantee the integrity of the data, all of the operations, included in a transaction, must be terminated with a successful change of the state of your data (in this case, the transaction is defined as committed). Otherwise, none of them must take effect (in this case, the transaction is rolled back, or aborted).

You can think of a transaction as a sort of mechanical aid to achieve data correctness.

Developers that use Java EE/Jakarta EE specifications have the ability to manage transactions in two ways, as follows:

• Container-managed transactions: This is the easiest way to handle transactions. Using Enterprise Java Bean (EJB) or a simple Java class with the @Transactional annotation, developers can delegate the life cycle of the transaction to a container that hides all of the complex processing necessary to handle the transaction. In this case, it's important to know and follow the rules and specifications of the platform and the container to know the exact behavior of your workflow, avoiding unexpected results.
• Bean-managed transactions: This is a fine-grained way to handle transactions. Developers are responsible for starting and ending the transaction, and deciding its final state (committed, aborted, or rolled back). The container will provide a transaction manager implementation, but it will not handle anything on behalf of the developer, who will have total control of the workflow, but no protection from bugs or low-quality code.