One of the javaee transaction literacy notes swept to the end

The speaker is in "muliang wenwang" and "Xiangsheng". Let's take a look at the following examples. Although it is practical, it is still a few dishes after the number of disks, Which is boring. In the future, it will not be a great waste. Please try to keep these notes in a quiet place on the Wiki.

1. Materials

• Java transaction design strategies; infoq minibook, the best electronic document, must be read for Java transactions in a state of ignorance.
• The article "expert one on one J2EE development without EJB Chinese version" and the relevant chapter in spring reference manual Chinese version documents can be seen in spring guys.

2. Local transactions and distributed transactions

• Local transaction
  It depends entirely on DB and JMS itself, such as directly calling conn. Commit () in JDBC; there is nothing to do with the application server, so global transactions for multiple data sources are not supported.
• Distributed transactions
  Transactions in the javaee world are implemented on JTA, JTs specifications, and XA sources.
  JTA is a user programming interface, and JTs is the underlying service of the server. The two are generally implemented by the application server, while atomikos kernel, jotm kernel, and JBoss transaction kernel are specialized in competition for business.
  XA sources exists before javaee. JDBC driver must have an implementation class of the javax. SQL. xadatasource interface. Otherwise, two-stage commit is a pseudo capability.
  In addition to JDBC and JMS, Java ee also introduces the JCA model. JCA can be said to be the only portable Resource Model for inserting javaee transactions. Therefore, frameworks/servers such as JDO rely on their own JCA connectors to participate in javaee transactions.

3. Programming Model

The method for manually calling the JDBC connection transaction and using the JTA interface are all programmed and called BMT (bean management transaction) in EJB ).
The most important interface of JTA is usertransaction and its six methods-begin, commit, rollback, getstatus, setrollbackonly, and settransactiontimeout.
The program can receive the usertransaction from JNDI, but the JNDI name varies with the application server. In ejb3, @ resource injection can be directly used.

4. declarative model

This is the main transaction model, such as the ejb cmt (container management transactions) and sprin.

Ejb2.0 and spring1.0 are defined in the deployment descriptor and applicationcontext. XML, while ejb3.0 and spring2.0 use annotation.

4.1 transaction type

The definitions of javaee and spring are basically the same:

• Required: if there is a transaction in the context, join the transaction and create one without it. (Most common settings)
• Mandatory: Always joins a transaction. If no transaction exists in the current context, an exception is thrown. (Those methods that do not intend to be responsible for rollback transactions must be added to others' transactions and controlled by others)
• Requiresnew: Creates a transaction forever. (Methods that must submit transactions, regardless of others, such as audit information, must be written)
• Supports: if a transaction exists, add it. If not, forget it. Never create a new transaction. (It is generally used for read-only methods and does not take the initiative to create a transaction. However, if a transaction exists, it is added to read uncommitted data in the transaction)
• Notsupported: Never use transactions. If there is a transaction, the transaction is suspended. (Methods that may throw exceptions but do not affect the global processing)
• Never: This method cannot be called in the case of the current transaction. (Isn't it near ?)

It can be seen that required is the default setting, and supports is the best choice for read-only methods.

4.2 transaction isolation level

• Readuncommited: This transaction shows the uncommitted data of another transaction. Dirty read.
• Readcommited: This transaction can only see the data committed by another transaction. It cannot be read repeatedly.
• Repeatableread: repeatableread. The data read for the first time in a transaction remains unchanged no matter how data is committed by another transaction before the transaction is committed.
• Serializable: serializable. Only one transaction can read the same data.

The lower the level, the lower the Security efficiency. The isolation level requires the support of related resources. For example, repeated reads in Oracle will be downgraded to readcommited. The default level in spring is completely dependent on the data source's face.

4.3 about rollback

In EJB, rollback can only be sessioncontext. setrollbackonly (), or an ejbexception is thrown. (Ejb3 can also set annotation to set some custom exceptions to trigger rollback)

In spring, only rollback unchecked exception (runtimeexcption and subclass) will be returned, while checked exception (exception and subclass) will not be rolled back unless you specifically declare it.

   @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW,rollbackFor = {MyException1.class,MyException2.class})

 

Therefore, all exceptions defined by throws in the service layer method must be rollback set in the transaction definition. (Do not forget)

All exceptions that are handled by atch in the service layer method, and if you want the container to assist rollback, you must re-throw a pre-defined runtimeexception subclass. (Please do not look back)

4.4 about spring

Spring does not want programmatic transaction management.
Spring does not want to use the EJB CMT--CMT to rely on EJB and cannot be used for pojo, relying on JTA global transaction to cause a waste of single data source scenarios, in addition, the rollback mechanism is troublesome (it must be ejbexception or manually setrollbackonly ()).
Therefore, spring implements a complete declarative Transaction System for pojo through AOP, and implements a unified transaction management mechanism for local data sources such as JDBC, hibernate, JPA, and JMS, it also supports switching between local resources and JTA at the configuration file level, and improves the rollback mechanism.

1) A local Transaction Manager:

<bean id="transactionManager"  class="org.springframework.orm.jpa.JpaTransactionManager">  <property name="entityManagerFactory" ref="entityManagerFactory" /> </bean>

 

2) spring will forward all requests to the JTA object of the Application Server (note that the data source also needs to be retrieved from the application server using JNDI ).

<bean id="myTxManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>

 

3) Dedicated JTA Transaction Manager of the Application Server:

<bean id="myTxManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager"/>

 

Bytes