Using EJBS for transaction management

Recently in the practice of Java project, encountered a lot of annotations, through the Baidu found, these annotations inside actually contains Brainiac, below I say @transactionmanagement

There are two ways to use transactions in EJBs. The first waytransactions managed through a container, called CMT (Container-managed Transaction), anothertransactions that are managed through beansCalled BMT (bean-managed Transaction).

If a container is used to manage transactions, then the EJB component does not need to explicitly give a begin, commit, abort statement, which the EJB container will consider for us. The EJB container defines the corresponding transaction boundary according to the transaction behavior specified by the EJB component provider.
When using a container to manage transactions, the EJB container intercepts the client request and automatically initiates a new transaction for the EJB build, that is, the container invokes the underlying transaction system through the BEGIN statement, which initiates the transaction. The container then delegates the business request to the EJB component, and the business operations in the component run in the transaction. An EJB component in a transaction can execute any business logic, such as writing to a database, sending asynchronous information, invoking other EJB components, and so on. Once a problem occurs during the processing of the business, the EJB build needs to notify the EJB container to roll back the transaction. When the EJB build completes the business process, control is handed back to the EJB container. The EJB container can then invoke the underlying transaction system through a commit or abort statement.
We can use @transactionattribute annotations or deployment descriptors to specify transaction properties. The EJB container can know how to handle the transaction requirements of the EJB component by parsing the transaction properties.

If you summarize the above in a short sentence, the transaction is managed by the CMT, the transactions are managed by the container, and the developer does not need to manage the transaction, so it is necessary to configure the transaction properties.

There are several values for EJB transaction properties:

(1) Required, you should use Required mode if the EJB component must always be running in a transaction. If a transaction is already running, the EJB component participates in it, and if no transaction is running, the EJB container initiates a new transaction for the EJB component.

Required is the default and most commonly used transaction property value. This value specifies that the EJB method must be called within a transaction. If a method is called from a non-transactional client, the container starts the transaction before the method is called and ends the transaction when the method returns. On the other hand, if the caller calls a method from a transactional context, the method joins the existing transaction. In the case of propagating a transaction from a customer segment, if our method indicates that the transaction should be rolled back, the container will not only roll over the entire transaction, but also throw an exception to the client, so that the client knows that the transaction it started has been rolled back by another method.

(2) Requires_new, when a customer invokes an EJB, if it always wants to start a new transaction, the RequiresNew transaction property should be used, and if the customer already has a transaction when invoking the EJB component, the current transaction is suspended, and the container starts a new transaction. and delegate the invocation request to the EJB component. That is, if the client already has a transaction, it pauses the transaction, knows where the method returns, and whether the new transaction succeeds or fails without affecting the client's existing transactions. The EJB component performs the corresponding business operation, the container commits or rolls back the transaction, the final container restores the original transaction, and of course, if the customer does not have a transaction when invoking the EJB component, then the transaction's suspend or resume operation is not required.

RequiresNew transaction properties are useful. If the EJB component requires the ACID properties of the transaction, and the EJB component is run in a single, separate unit of work, so that no other external logic is included in the current transaction, you must use the Requirednew transaction property. If a transaction is required, but you do not want the rollback of the transaction to affect the client, you should use it. Also, you should use this value when you do not want the rollback of the client to affect you.

(3) Supports, if an EJB component uses the Supports transaction property, this EJB component will run in the transaction only if the client that invoked it has already enabled the transaction. If the customer is not running in a transaction, then the EJB build will not run in the transaction. Supports is similar to Required transaction properties, however, Required requires that the EJB component must be running in a transaction. If you use the support transaction attribute, it is likely that the EJB build is not running in the transaction.

(4) Mandatory, the Mandatory transaction property requires that the client calling the EJB component must already be running in the transaction. If you invoke an EJB method that uses the mandatory property from a non-transactional client, the client will accept the javax.ejb.EJBTransactionRequiredException exception thrown by the system. The EJB component uses the mandatory transaction property to be very secure, which ensures that the EJB build runs in the transaction. If the customer is not running in the transaction, it cannot be called to the EJB component that has the mandatory transaction attribute applied. However, the Mandatory transaction property requires that 3rd parties (and customers) must start a transaction before invoking the EJB component. The EJB container does not automatically start a new transaction for the mandatory transaction property, which is the main difference from the support transaction property.

(5) NotSupported, if the EJB component uses the Notsupport transaction attribute, it will not participate in the transaction at all. If the caller uses the associated transaction to invoke the method, the container pauses the transaction, invokes the method, and then resumes the transaction when the method returns. Typically, this property is used only in non-physical auto-acknowledgement mode, which supports the JMS provider's MDB.

(6) Never, if the EJB component uses the Never transaction property, it cannot participate in the transaction, and if the client that invokes it is already in the transaction, the container throws the Javax.ejb.EJBException exception to the customer.

             of course, in the properties listed above, our most commonly used or required specifically can see the following snippet code :

<span style= "FONT-SIZE:18PX;" >import Javax.ejb.remote;import Javax.ejb.stateless;import Javax.ejb.transactionattribute;import Javax.ejb.transactionattributetype;import Javax.ejb.transactionmanagement;import Javax.ejb.transactionmanagementtype;import Javax.persistence.entitymanager;import Javax.persistence.PersistenceContext; @Stateless (name = "Usermanager") @Remote @transactionmanagement ( Transactionmanagementtype.container) public class Usermanagerbean implements Usermanager {   @PersistenceContext    private Entitymanager em;    @TransactionAttribute (transactionattributetype.required) public   void AddUser (String name) {      User s = new User ( );      S.setname (name);      Em.persist (s);      SYSTEM.OUT.PRINTLN ("Server-side Execution succeeded: Save name" + name);}     } </span>

          

In the example above

@TransactionManagement (Transactionmanagementtype.container) represents the type of the specified transaction. If omitted, the default is CMT mode.

@TransactionAttribute (transactionattributetype.required) notifies the container how the transaction is managed, and the properties of the transaction control the use of the transaction, because the relationship between the transactions is very complex, This property is primarily used to deal with the problem of how transactions are handled between transactions.

The above is the EJB container for transaction management, here we also found a note: @ Stateless

Let me tell you the meaning of this note:

1) Stateful session Bean: each user has its own unique instance, during the lifetime of the user, the bean maintains the user's information, namely "stateful"; Once the user dies (the end of the call or the end of the instance), the bean's lifetime ends. That is, each user will initially get an initial bean. Life cycle We can use the context of the Web to understand simple, such as session, request and so on. During this life cycle, users will only get a specific stateful session bean.

2) Stateless session Bean:bean once instantiated is added to the session pool, each user can be shared. Even if the user has died, the lifetime of the bean does not necessarily end, it may still exist in the session pool for other users to invoke. Because there is no specific user, it is not possible to maintain a user's state, so called a stateless bean. However, a stateless session bean is not stateless, and if it has its own attributes (variables), then these variables will be affected by all users who invoke it, which must be noted in practical applications.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Transaction management with EJBS