TransactionSynchronization (Spring Framework API 2.1) - Spring Framework 2.1.0 API 文档英文版

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

The Spring Framework

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

org.springframework.transaction.support
Interface TransactionSynchronization

All Known Implementing Classes:: SpringLobCreatorSynchronization, TransactionSynchronizationAdapter

public interface TransactionSynchronization

Interface for transaction synchronization callbacks. Supported by AbstractPlatformTransactionManager.

TransactionSynchronization implementations can implement the Ordered interface to influence their execution order. A synchronization that does not implement the Ordered interface is appended to the end of the synchronization chain.

System synchronizations performed by Spring itself use specific order values, allowing for fine-grained interaction with their execution order (if necessary).

Since:: 02.06.2003
Author:: Juergen Hoeller
See Also:: TransactionSynchronizationManager, AbstractPlatformTransactionManager, DataSourceUtils.CONNECTION_SYNCHRONIZATION_ORDER, SessionFactoryUtils.SESSION_SYNCHRONIZATION_ORDER

Field Summary

static int STATUS_COMMITTED
          Completion status in case of proper commit

static int STATUS_ROLLED_BACK
          Completion status in case of proper rollback

static int STATUS_UNKNOWN
          Completion status in case of heuristic mixed completion or system errors

Method Summary

void afterCommit()
          Invoked after transaction commit.

void afterCompletion(int status)
          Invoked after transaction commit/rollback.

void beforeCommit(boolean readOnly)
          Invoked before transaction commit (before "beforeCompletion").

void beforeCompletion()
          Invoked before transaction commit/rollback.

void resume()
          Resume this synchronization.

void suspend()
          Suspend this synchronization.

Field Summary
`static int`	`STATUS_COMMITTED` Completion status in case of proper commit
`static int`	`STATUS_ROLLED_BACK` Completion status in case of proper rollback
`static int`	`STATUS_UNKNOWN` Completion status in case of heuristic mixed completion or system errors

Method Summary
`void`	`afterCommit()` Invoked after transaction commit.
`void`	`afterCompletion(int status)` Invoked after transaction commit/rollback.
`void`	`beforeCommit(boolean readOnly)` Invoked before transaction commit (before "beforeCompletion").
`void`	`beforeCompletion()` Invoked before transaction commit/rollback.
`void`	`resume()` Resume this synchronization.
`void`	`suspend()` Suspend this synchronization.

Field Detail

STATUS_COMMITTED

static final int STATUS_COMMITTED

Completion status in case of proper commit

See Also:: Constant Field Values

STATUS_ROLLED_BACK

static final int STATUS_ROLLED_BACK

Completion status in case of proper rollback

See Also:: Constant Field Values

STATUS_UNKNOWN

static final int STATUS_UNKNOWN

Completion status in case of heuristic mixed completion or system errors

See Also:: Constant Field Values

Method Detail

suspend

void suspend()

Suspend this synchronization. Supposed to unbind resources from TransactionSynchronizationManager if managing any.

See Also:: TransactionSynchronizationManager.unbindResource(java.lang.Object)

resume

void resume()

Resume this synchronization. Supposed to rebind resources to TransactionSynchronizationManager if managing any.

See Also:: TransactionSynchronizationManager.bindResource(java.lang.Object, java.lang.Object)

beforeCommit

void beforeCommit(boolean readOnly)

Invoked before transaction commit (before "beforeCompletion"). Can e.g. flush transactional O/R Mapping sessions to the database.

This callback does not mean that the transaction will actually be committed. A rollback decision can still occur after this method has been called. This callback is rather meant to perform work that's only relevant if a commit still has a chance to happen, such as flushing SQL statements to the database.

Note that exceptions will get propagated to the commit caller and cause a rollback of the transaction.

Parameters:: readOnly - whether the transaction is defined as read-only transaction
Throws:: RuntimeException - in case of errors; will be propagated to the caller (note: do not throw TransactionException subclasses here!)
See Also:: beforeCompletion()

beforeCompletion

void beforeCompletion()

Invoked before transaction commit/rollback. Can perform resource cleanup before transaction completion.

This method will be invoked after beforeCommit, even when beforeCommit threw an exception. This callback allows for closing resources before transaction completion, for any outcome.

Throws:: RuntimeException - in case of errors; will be logged but not propagated (note: do not throw TransactionException subclasses here!)
See Also:: beforeCommit(boolean), afterCompletion(int)

afterCommit

void afterCommit()

Invoked after transaction commit. Can perform further operations right after the main transaction has successfully committed.

Can e.g. commit further operations that are supposed to follow on a successful commit of the main transaction, like confirmation messages or emails.

NOTE: The transaction will have been committed already, but the transactional resources might still be active and accessible. As a consequence, any data access code triggered at this point will still "participate" in the original transaction, allowing to perform some cleanup (with no commit following anymore!), unless it explicitly declares that it needs to run in a separate transaction. Hence: Use PROPAGATION_REQUIRES_NEW for any transactional operation that is called from here.

Throws:: RuntimeException - in case of errors; will be propagated to the caller (note: do not throw TransactionException subclasses here!)

afterCompletion

void afterCompletion(int status)

Invoked after transaction commit/rollback. Can perform resource cleanup after transaction completion.

NOTE: The transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible. As a consequence, any data access code triggered at this point will still "participate" in the original transaction, allowing to perform some cleanup (with no commit following anymore!), unless it explicitly declares that it needs to run in a separate transaction. Hence: Use PROPAGATION_REQUIRES_NEW for any transactional operation that is called from here.

Parameters:: status - completion status according to the STATUS_* constants
Throws:: RuntimeException - in case of errors; will be logged but not propagated (note: do not throw TransactionException subclasses here!)
See Also:: STATUS_COMMITTED, STATUS_ROLLED_BACK, STATUS_UNKNOWN, beforeCompletion()