Transaction management in Java EE--demarcation of transaction

In the previous blog, the general introduction of transactions, in fact, in the enterprise Application server transactions are at different levels exist. A relatively simple transaction is the bottom-level transaction, which is the transaction management at the resource levels. Assuming that the data is ultimately stored in a relational database, the lowest-level transaction is located here. We call this a resource-local transaction (resource-localtransaction) in most cases where the developer has to deal with a transaction that is not in the container (other things are not enough because of the level!). ）。 It is easy to resolve resource-local transactions by understanding the data's transactions. If you are using an enterprise application server, then most of the transactions that you are dealing with are the Javatransaction API (Java Transaction API, abbreviated as JTA), which apply to all servers that implement Java EE annotations. Since the container is involved in the transaction, it is necessary to serve the developer, so it can be convenient for developers when dealing with multiple resources. Resources defined by the Java Connector Architecture (Javaconnector ARCHITECTURE,JCA) component can also be used in container transactions. (This is the official document words in fact, I do not really understand; P

Transactions in containers typically add their own processing rules on top of JDBC to perform functions such as connection management and pooling. The simple thing to do is to get the developers out of the tedious operation of JDBC, and the container to do things that can be done by the machine. Of course, after the transaction of the container itself is complete, it performs a commit or rollback of the data source (previously this was a manual intervention by the developer).

more sharp than the general transaction is that the container transaction can cross the data source, so the container transaction has another name -- JTA Transaction (also known as global transaction transaction).

Here is the question of the demarcation of the transaction (transaction demarcation). It is well known that a transaction either succeeds in committing the data to the database, or rolls back without doing anything. The behavior that causes the transaction to be completed or rolled back is what we call a transactional demarcation. In fact, the demarcation can also have a more simple way of understanding, so-called transaction demarcation is the boundary between two transactions, then how to distinguish between the boundaries? Only one transaction completion is the start of another transaction, so the commit or rollback of a transaction marks the completion of the transaction. When a container is not being used, it is submitted or rolled back by the developer as shown by the resource's local transaction. The situation is different when using the container, because the container encapsulates a lot of things for the developer, so when the boundary is demarcated, the developer can either be completely disposed of by the container or be able to intervene on its own. The former is completely given to the container to control the transaction management we call container hosting (container-managed); the latter is what we call a bean-managed (bean-managed) transaction management.

When using the EJB container, we arbitrarily choose two kinds of transaction management methods, but when using the servlet container, we can only select the bean-hosted transaction. The container is managed by default in the EJB container, and of course it can be configured as a bean-managed transaction, as in the following code.

@Stateless @transactionmanagement (Transactionmanagementtype.bean) public class Projectservicebean implements Projectservice {    //methods here}

Because the transaction in the EJB container is managed by default, it is only when we expect the bean to be hosted that the above annotations are specifically made.

The following articles describe container managed transactions and Bean managed transactions, respectively.

Transaction management in Java EE--demarcation of transaction