Transaction with Spring Framework

Posted on by

Support model

  • Global transactions
  • Work with multiple transactional resources
  • Through the JTA, which normally needs to be sourced from JNDI

  • Local transactions

  • Resource-specific (like a JDBC transaction)

PlatformTransactionManager

public interface PlatformTransactionManager {

TransactionStatus getTransaction(
TransactionDefinition definition) throws TransactionException;

void commit(TransactionStatus status) throws TransactionException;

void rollback(TransactionStatus status) throws TransactionException;
}
  • The primarily service provider interface (SPI)
  • Could be easily mocked or stubbed
  • Not tied to a lookup strategy such as JNDI.

常用TransactionManager (程式碼範例: Transaction Strategies)

  • DataSourceTransactionManager (a example with plain JDBC)
  • JtaTransactionManager
  • HibernateTransactionManager (needs a reference to the SessionFactory)

TransactionDefinition specifies

API here

Propagation

Propagation If current transaction exist If current transaction NONE exist
REQUIRED (default) Support the current transaction Create a new one
SUPPORTS Support the current transaction Execute non-transactionally
MANDATORY Support the current transaction Throw an exception
REQUIRES_NEW Create a new one and suspending the current transaction Create a new one
NOT_SUPPORTED Always execute non-transactionally Always execute non-transactionally
NEVER Throw an exception Execute non-transactionally
NESTED Execute within a nested transaction Create a new one

Nested: Only applies to the JDBC DataSourceTransactionManager when working on a JDBC 3.0 driver.
see more @ Transaction propagation

Isolation level:

Isolation Dirty reads Non-repeatable reads Phantom reads
READ_UNCOMMITTED can occur can occur can occur
READ_COMMITTED prevented can occur can occur
REPEATABLE_READ prevented prevented can occur
SERIALIZABLE prevented prevented prevented
DEFAULT Use the default isolation level of the underlying datastore.

Ready-only

This just serves as a hint for the actual transaction subsystem; it will not necessarily cause failure of write access attempts. A transaction manager which cannot interpret the read-only hint will not throw an exception when asked for a read-only transaction.

Declarative transaction management

Roll back is automatic only on unchecked exceptions (Spring default behavior)

<br /><br /><br /><!-- 可以定義除了RuntimeException以外, 哪些Exception也要(或不要)rollback, including checked exceptions. -->

You can also indicate a required rollback programmatically. see more @ Programmatic transaction

public void resolvePosition() {
try {
// some business logic...
} catch (NoProductInStockException ex) {
// trigger rollback programmatically
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
}
}

REQUIRES情境

起始Method (A) 中間Method (B) 例外 結果
Tx Method 任何情況 無 Commit
Tx Method 任何情況 丟出RuntimeException Rollback all
ReadOnly Tx Method 本支程式另一個Tx Method 無 兩個Method在同一個ReadOnly Tx中, Commit
ReadOnly Tx Method 另一支程式的Tx Method 無 延用ReadOnly Tx, Commit

REQUIRES_NEW情境

起始Method (A) 中間Method (B) 例外 結果
Tx Method 本支程式另一個Tx Method 無 兩個Method在同一個Tx中, Commit
Tx Method 另一支程式的Tx Method 無 B會取得自己的Tx, 兩個Tx都Commit
Tx Method 另一支程式的Tx Method B丟RuntimeException B會取得自己的Tx, 兩個Tx都Rollback
Tx Method 另一支程式的Tx Method A在呼叫B之前丟出RuntimeException B不會取得Tx, A Rollback
Tx Method 另一支程式的Tx Method A在呼叫B之後丟出RuntimeException B會取得自己的Tx, B Commit, A Rollback
ReadOnly Tx Method 本支程式另一個Tx Method 無 兩個Method在同一個ReadOnly Tx中, Commit
ReadOnly Tx Method 另一支程式的Tx Method 無 B會產生自己的Tx, 不延用A的ReadOnly Tx, Commit

Leave a comment