Transaction processing behavior

The readers of this article are mainly enterprise Bean providers. For example, they are responsible for developing components on the server.ProgramMember. This article explains how to define the transaction processing of an EJB application.

The following is a summary of this article:

1. For readers and the contents of this article

2. Declarative Transaction Management

3. Bean-managed transactions

4. Distributed Transaction Management

Declarative Transaction Management

In the case of the container management transaction management method, the transaction processing behavior of the enterprise Bean is defined during configuration, it is embodied in the Assembly-Descriptor element section of the standard deployment descriptor file. during configuration, we can define a common transaction processing behavior for all the methods (methods) in the same bean, or define different transaction processing behaviors for each method (methods. we configure the transaction behavior by specifying the transaction attribute. the transaction attributes are as follows:

• Notsupported:If this method is called in a transaction context, the transaction will be suspended during the execution of this method.

• Required: If this method is called in a transaction context, it is executed in the transaction context. otherwise (this method is not called in the context of a transaction), the Container automatically generates a new transaction before the method is executed, and then the method is executed in the context of the new transaction, at the end of the method, the container will automatically submit the newly generated transaction.

• Requiresnew: This method always requires execution in a new transaction context. before the method is executed, the container will automatically generate a new transaction, and the container will automatically submit the newly generated transaction when the method returns. if this method is called in the context of a transaction, the transaction will be suspended at the beginning of the new transaction, and the transaction will be restarted after the new transaction ends.

• Mandatory: This method is always required to be called in a transaction context. Otherwise, the container will throw the transactionrequired exception.

• Supports: If this method is called in a transaction context, it will be executed in the transaction context. if the caller of the method is not in the transaction context, the method is not executed in any transaction context.

• Never: This method requires that the caller of this method cannot be in the transaction context. Otherwise, the container will throw the RemoteException.

The table description is as follows:

Transaction attributes	Caller transaction	Enterprise Bean method transaction
Notsupported	- T1	- -
Required	- T1	T2 T1
Requiresnew	- T1	T2 T2
Mandatory	- T1	Error T1
Supports	- T1	- T1
Nervere	- T1	- Error

According to the requirements of the EJB specification, the transaction attributes are set in the integration Descriptor (assembly-Descriptor) of the deployment descriptor. For example:

<Assembly-Descriptor>  <Container-transaction>  <Method>  <EJB-Name> accountimpl </EJB-Name>  <Method-Name> * </method-Name>  </Method>  <Trans-attribute> supports </trans-attribute>  </Container-transaction>  <Container-transaction>  <Method>  <EJB-Name> accountimpl </EJB-Name>  <Method-Name> getbalance </method-Name>  </Method> <Trans-attribute> required </trans-attribute>  </Container-transaction>  <Container-transaction>  <Method>  <EJB-Name> accountimpl </EJB-Name>  <Method-Name> setbalance </method-Name>  </Method>  <Trans-attribute> mandatory </trans-attribute>  </Container-transaction>  </Assembly-Descriptor>   

In this example, all accountimpl bean methods that do not use the container-transaction element are explicitly specified, and the default transaction attribute supports (matching character * specifies the default transaction attribute, applies to all methods of the bean )). specifically, the transaction attributes of getbalance and setbalance methods are required and mandatory (by specifying the specific method name ).

Bean-managed transactions

For beans that manage their own transactions, the corresponding transaction-type element must be set in the standard deployment descriptor. For example:

 
<Transaction-type> bean </transaction-type>
 

for transactions managed by beans, bean programmers should use javax. transaction. usertransaction to define the transaction boundary. this interface (Interface) javax. transaction. usertransaction by Implementation of the EJB server on an object inside the server . you can call ejbcontext. getusertransaction () to obtain this interface (ejbcontext here varies depending on the bean type session bean or Entity Bean. In Session Bean, ejbcontext refers to sessioncontext, in Entity Bean ejbcontext, it refers to entitycontext ). the following example defines the transaction boundary in the "dotxjob" method of the Session Bean. The usertransaction object (Interface) is obtained through the sessioncontext object. the sessioncontext object is passed as a parameter in the bean initialization method setsessioncontext (which is automatically called by ejbserver during bean initialization. (this means that bean programmers should setsessioncontext stores the sessioncontext object in bean variables ). (See example of the Session Bean ).

Public void dotxjob () throws RemoteException {Usertransaction ut = sessioncontext. getusertransaction ();Ut. Begin ();... // Transactional operationsUt. Commit ();}
 

AnotherThe method to obtain the interface usertransaction is to use JNDI, that is, in the initialization contextJava: Get the name of COMP/usertransaction.

Distributed Transaction Management

As mentioned above, the transaction behavior of an application can be defined through declaration, or assisted by bean or bean callers, respectively, in programmingCodeSpecified in (Define transaction boundaries). No matter where the transaction is, whether it is for bean provider or application integrator .) it is completely transparent. this means that a transaction may involve multiple beans on different EJB servers, and the platform should manage distributed transactions globally. the platform uses the two-phase commit protocol (two phase commit) between multiple different servers to manage distributed transactions, so that bean programmers do not need to consider the distribution characteristics of transactions.

After been has been developed and application integration is complete, deployer or administrator) different bean configurations can also be distributed on the same or multiple different EJB servers on the same or multiple different machines.

This configuration process can be completed without code changes or deployment descriptor modifications. the distributed configuration is specified at launch time: in the Environment properties of an EJB server, you may specify the configuration of distributed transactions when the EJB server is started: therefore, the configuration of distributed transactions is set in the Environment configuration file of the EJB server. the settings are as follows:

• Which Enterprise beans will the EJB server manage?

• Specifies whether to start a Java transaction Monitor (JTM) simultaneously in the JVM Of The EJB server ).

This must be done by setting the environment configuration fileJonas. Service. EJB. descriptors and Jonas. Service. JTM. Remote items in Jonas. properties are completed.The previous one lists all the enterprise beans managed in the EJB server (by specifying the deployment descriptor file name or EJB-JAR file name), and the last one sets the Java transaction Monitor (JTM) Startup Mode:

• If this parameter is set to true, JTM uses the remote method, that is, JTM must be started in another JVM before the EJB server is started.

• If set to false, the JTM is local, I. e. it will run into the same JVM as the EJB server. if this parameter is set to false, JTM uses the local method, that is, JTM is started in the JVM Of The EJB server.

For example:

 
Jonas. Service. EJB. descriptors bean1.xml, bean2.xmlJonas. Service. JTM. Remote false
 

JTM can be run in a separate JVM without necessarily running in an EJB server. In this case, run the following command to start JTM separately:

 
Tmserver
 

With this flexible configuration method, you can use different configurations based on the specific situation of resources (CPU or data source) to obtain the best system performance.

The following figure shows four different configurations for three enterprise beans,

1. 1st cases: three enterprise beans B1, B2 and B3 are distributed in the same EJB server, and a Java transaction monitor is started simultaneously in the EJB server.

2. 2nd cases: three enterprise beans are distributed on different EJB servers. Only one EJB server starts a Java transaction monitor to manage globally distributed transactions.

3. 3rd cases: three enterprise beans are distributed in different EJB servers, and JTM runs in each separate JVM.

4. 4th cases: three enterprise beans are distributed in different EJB servers. each EJB server starts a Java transaction monitor. one of them serves as the master Monitor and the other two as the slave Monitor (slaves .)

These different configurations can be achieved by configuring the environment attribute configuration file corresponding to the EJB server and then starting the EJB server. In some cases, JTM needs to be started (in 3rd cases ). the basic principle is to make appropriate choices based on the resource location and Server Load balancer. the following are some explanations for your reference:

• If Enterprise beans need to run on the same machine and the same EJB server configuration is required, 1st cases should be the best choice.

• If Enterprise beans require running on different machines, 4th cases should be the best choice, because local transaction management is more suitable.

• If Enterprise beans require running on the same machine and different EJB server configurations, 2nd cases should be a good choice.