J2EE transaction trap

See: http://www.ibm.com/developerworks/cn/java/j-ts1.html

 

1. An ORM-based framework requires a transaction to trigger synchronization between the object cache and the database, for example, in the Spring framework

Solution:@ TransactionalAdd the annotation to the crud method and declare the transaction management bean in the spring configuration file as follows:

 
<TX: annotation-driven transaction-Manager = "transactionmanager"/>
 

 

 

2. @ Transactional Read-only flag traps

 

@ Transactional (readonly = true, propagation = propagation. Supports)
In spring JDBC (non-ORM), the propagation mode is setSupportsTherefore, no transactions are started. Therefore, this method effectively utilizes a local (database) transaction. The read-only flag applies only when the transaction starts. In this example, the read-only flag is ignored because no transaction is started.

Note:Local transaction, Also knownDatabase transactions,It is done by the database. A local transaction is a logical unit of work (luw) that executes a single insert, update, or delete statement ). I understand that the default JDBC automatic commit refers to the local transaction here.

 

@ Transactional (readonly = true, propagation = propagation. required)

In spring JDBC, an exception is thrown, indicating that you are trying to update a read-only connection. Because a transaction (Required), So the connection is set to read-only. There is no doubt that when you try to execute an SQL statement, you will get an exception telling you that the connection is a read-only connection.

 

In spring JPA, the preceding transaction statement works normally. When using an ORM-based framework, the read-only flag only prompts the database and sets the flush mode of object cacheNeverIndicates that the object cache should not be synchronized with the database in this work unit. However,RequiredThe propagation mode will overwrite all the content and allow the transaction to start and work, just as if the read-only flag is not set.

 

@ TransactionalThe default propagation mode of the annotation isRequired. This means that the transaction will be started without any need. Based on the database used, this will cause unnecessary shared locks and may cause deadlocks in the database. In addition, starting and stopping transactions consume unnecessary processing time and resources. In general, when using an ORM-based framework, the read-only flag is basically useless and will be ignored in most cases. However, if you stick to it, remember to set the propagation modeSupports(As shown in listing 9), the transaction will not be started.

 

This article emphasizes read operations to avoid using@ TransactionalAnnotations, that is, do not start things. I suspect that, just like multi-threaded operations on the same data, you do not need to perform synchronized on get/set at the same time.

 

3.Requires_newTransaction property trap

 

If method 1 calls method 2, and method 1 and 2 are declared as require_new. After method 2 is successfully called in method 1, ifCodeIf an exception occurs, method 1 will be rolled back, and method 2 will not. Therefore, require_new is rarely used. GenerallyMandatoryOrRequiredAttribute. However, this statement is required in a special business environment. For example, use the audit methodRequires_newAttribute. audit data is saved regardless of the transaction result.

 

4.Transaction rollback trap

 

In spring, the rollback of the entire logical unit of work is automatically enforced due to runtime exceptions (uncontrolled exceptions), but the checked exception is not

 

You can also declare exceptions that require rollback:

@ Transactional (propagation = propagation. required, rollbackfor = Exception. Class)

In terms of rollback transactions, EJB works in a slightly different way than spring framework. In the EJB 3.0 specification@ TransactionattributeThe comment does not contain the command for the specified rollback behavior. RequiredSessioncontext. setrollbackonly ()Method To Mark transactions as performing rollback,