在下面的文章中，我講會多次提到第一篇文章，第一篇文章是：Spring聲明式事務管 理源碼解讀之事務開始
如果要理解事務提交的話，理解事務開始是一個前提條件,所以請先看第一篇文章，再 來看這篇
如果你仔細看下去，我想肯定是有很多收獲，因為我們確實能從spring的代碼和思想 中學到很多東西。
正文：
其實俺的感覺就是事務提交要比事務開始復雜，看事務是否提交我們還是要回到 TransactionInterceptor類的invoke方法
Java代碼
public Object invoke(MethodInvocation invocation) throws Throwable {
// Work out the target class: may be <code>null</code>.
// The TransactionAttributeSource should be passed the target class
// as well as the method, which may be from an interface
Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;
// Create transaction if necessary.
TransactionInfo txInfo = createTransactionIfNecessary (invocation.getMethod(), targetClass);
Object retVal = null;
try {
// This is an around advice.
// Invoke the next interceptor in the chain.
// This will normally result in a target object being invoked.
retVal = invocation.proceed();
}
catch (Throwable ex) {
// target invocation exception
doCloseTransactionAfterThrowing(txInfo, ex);
throw ex;
}
finally {
doFinally(txInfo);//業務方法出棧後必須先執行的一個方法
}
doCommitTransactionAfterReturning(txInfo);
return retVal;
}
其中的doFinally(txInfo)那一行很重要，也就是說不管如何，這個doFinally方法都 是要被調用的，為什麼它這麼重要呢，舉個例子:
我們還是以propregation_required來舉例子吧，假設情況是這樣的，AService中有一 個方法調用了BService中的，這兩個方法都處在事務體之中，他們的傳播途徑都是 required。那麼調用開始了，AService的方法首先入方法棧，並創建了TransactionInfo 的實例，接著BService的方法入棧，又創建了一個TransactionInfo的實例，而重點要說 明的是TransactionInfo是一個自身關聯的內部類，第二個方法入棧時，會給新創建的 TransactionInfo的實例設置一個屬性，就是TransactionInfo對象中的private TransactionInfo oldTransactionInfo;屬性，這個屬性表明BService方法的創建的 TransactionInfo對象是有一個old的transactionInfo對象的，這個oldTransactionInfo 對象就是AService方法入棧時創建的TransactionInfo對象，我們還記得在 createTransactionIfNecessary方法裡有這樣一個方法吧：
Java代碼
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
// We always bind the TransactionInfo to the thread, even if we didn't create
// a new transaction here. This guarantees that the TransactionInfo stack
// will be managed correctly even if no transaction was created by this aspect.
txInfo.bindToThread();
return txInfo;
}
就是這個bindToThread()方法在作怪：
private void bindToThread() {
// Expose current TransactionStatus, preserving any existing transactionStatus for
// restoration after this transaction is complete.
oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get();
currentTransactionInfo.set(this);
}
如果當前線程中已經有了一個TransactionInfo，則拿出來放到新建的 transactionInfo對象的oldTransactionInfo屬性中，然後再把新建的TransactionInfo設 置到當前線程中。
這裡有一個概念要搞清楚，就是TransactionInfo對象並不是表明事務狀態的對象，表 明事務狀態的對象是TransactionStatus對象，這個對象同樣是TransactionInfo的一個屬 性（這一點，我在前面一篇文章中並沒有講清楚）。
接下來BService中的那個方法返回，那麼該它退棧了，它退棧後要做的就是doFinally 方法，即把它的oldTransactionInfo設置到當前線程中（這個TransactionInfo對象顯然 就是AService方法入棧時創建的，怎麼現在又要設置到線程中去呢，原因就是BService的 方法出棧時並不提交事務，因為BService的傳播途徑是required，所以要把棧頂的方法所 創建transactioninfo給設置到當前線程中），即調用AService的方法時所創建的 TransactionInfo對象。那麼在AServie的方法出棧時同樣會設置TransactionInfo對象的 oldTransactionInfo到當前線程，這時候顯然oldTransactionInfo是空的，但AService中 的方法會提交事務，所以它的oldTransactionInfo也應該是空了。
在這個小插曲之後，麼接下來就應該是到提交事務了，之前在AService的方法出棧時 ，我們拿到了它入棧時創建的TransactionInfo對象，這個對象中包含了AService的方法 事務狀態。即TransactionStatus對象，很顯然，太顯然了，事務提交中的任何屬性都和 事務開始時的創建的對象息息相關，這個TransactionStatus對象哪裡來的，我們再回頭 看看createTransactionIfNessary方法吧：
Java代碼
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
txInfo.newTransactionStatus (this.transactionManager.getTransaction(txAttr));
}
再看看transactionManager.getTransaction(txAttr)方法吧：
Java代碼
public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {
else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
if (debugEnabled) {
logger.debug("Creating new transaction with name [" + definition.getName() + "]");
}
doBegin(transaction, definition);
boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);//注意這裡的返回值，返回的就是一個 TransactionStatus對象,這個對象表明了一個事務的狀態，比如說是否是一個新的事務， 事務是否已經結束，等等，這個對象是非常重要的，在事務提交的時候還是會用到它的。 }
}
}
還有一點需要說明的是，AService的方法在執行之前創建的transactionstatus確實是 通過這個方法創建的，但是，BService的方法在執行之前創建transactionstatus的方法 就與這個不一樣了，下面會有詳解。
回顧了事務開始時所調用的方法之後，是不是覺得現在對spring如何處理事務越來越 清晰了呢。由於這麼幾個方法的調用，每個方法入棧之前它的事務狀態就已經被設置好了 。這個事務狀態就是為了在方法出棧時被調用而准備的。
讓我們再次回到BService中的方法出棧的那個時間段，看看spring都做了些什麼，我 們知道，後入棧的肯定是先出棧，BService中的方法後入棧，拿它肯定要先出棧了，它出 棧的時候是要判斷是否要提交事務，釋放資源的，讓我們來看看TransactionInterceptor 的invoke的最後那個方法doCommitTransactionAfterReturning：
Java代碼
protected void doCommitTransactionAfterReturning(TransactionInfo txInfo) {
if (txInfo != null && txInfo.hasTransaction()) {
if (logger.isDebugEnabled()) {
logger.debug("Invoking commit for transaction on " + txInfo.joinpointIdentification());
}
this.transactionManager.commit(txInfo.getTransactionStatus ());
//瞧：提交事務時用到了表明事務狀態的那個TransactionStatus對象了。
}
}
看這個方法的名字就知道spring是要在業務方法出棧時提交事務，貌似很簡單，但是 事實是這樣的嗎？ 我們接著往下看。
Java代碼
public final void commit(TransactionStatus status) throws TransactionException {
DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status;
if (defStatus.isCompleted()) {
throw new IllegalTransactionStateException(
"Transaction is already completed - do not call commit or rollback more than once per transaction");
}
if (defStatus.isLocalRollbackOnly()) {
if (defStatus.isDebug()) {
logger.debug("Transactional code has requested rollback");
}
processRollback(defStatus);
return;
}
if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) {
if (defStatus.isDebug()) {
logger.debug("Global transaction is marked as rollback-only but transactional code requested commit");
}
processRollback(defStatus);
throw new UnexpectedRollbackException(
"Transaction has been rolled back because it has been marked as rollback- only");
}
processCommit(defStatus);
}
上面這段代碼就是transactionmanager中的commit，但是看上去，它又把自己的職責 分配給別人了，從代碼裡我們看到，如果事務已經結束了就拋異常，如果事務是 rollbackonly的，那麼就rollback吧，但是按照正常流程，我們還是想來看一下，事務的 提交，就是processCommit(status)這個方法吧。
Java代碼
private void processCommit(DefaultTransactionStatus status) throws TransactionException {
try {
boolean beforeCompletionInvoked = false;
try {
triggerBeforeCommit(status);
triggerBeforeCompletion(status);
beforeCompletionInvoked = true;
if (status.hasSavepoint()) {
if (status.isDebug()) {
logger.debug("Releasing transaction savepoint");
}
status.releaseHeldSavepoint();
}
else if (status.isNewTransaction()) {//這個判斷非常重要，下 面會詳細講解這個判斷的作用
if (status.isDebug()) {
logger.debug("Initiating transaction commit");
}
boolean globalRollbackOnly = status.isGlobalRollbackOnly();
doCommit(status);
// Throw UnexpectedRollbackException if we have a global rollback-only
// marker but still didn't get a corresponding exception from commit.
`````````````````````
}
我們注意到，在判斷一個事務是否是新事務之前還有一個status.hasSavepoint()的判 斷，我認為這個判斷事實上就是嵌套事務的判斷，即判斷這個事務是否是嵌套事務，如果 不是嵌套事務，則再判斷它是否是一個新事務，下面這段話就非常重要了，BService的中 的方法是先出棧的，也就是說在調用BService之前的創建的那個事務狀態對象在這裡要先 被判斷，但是由於在調用BService的方法之前已經創建了一個Transaction和Session（假 設我們使用的是hibernate3），這時候在創建第二個TransactionInfo（再強調一下吧， TransactionInfo並不是Transaction，Transaction是真正的事務對象，TransactionInfo 只不過是一個輔助類而已，用來記錄一系列狀態的輔助類）的TransactionStatus的時候 就會進入下面這個方法（當然在這之前會判斷一下當前線程中是否已經有了一個 SessionHolder對象，不清楚SessionHolder作用的同學情況第一篇文章），這個方法其實 應該放到第一篇文章中講的，但是想到如果不講事務提交就講這個方法好像沒有這麼貼切 ，廢話少說，我們來看一下吧：
Java代碼
private TransactionStatus handleExistingTransaction(
TransactionDefinition definition, Object transaction, boolean debugEnabled)
throws TransactionException {
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NEVER) {
throw new IllegalTransactionStateException(
"Transaction propagation 'never' but existing transaction found");
}
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) {
if (debugEnabled) {
logger.debug("Suspending current transaction");
}
Object suspendedResources = suspend(transaction);
boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS);
return newTransactionStatus(
definition, null, false, newSynchronization, debugEnabled, suspendedResources);
}
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {
if (debugEnabled) {
logger.debug("Suspending current transaction, creating new transaction with name [" +
definition.getName() + "]");
}
Object suspendedResources = suspend(transaction);
doBegin(transaction, definition);
boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
return newTransactionStatus(
definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);
}
if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
if (!isNestedTransactionAllowed()) {
throw new NestedTransactionNotSupportedException(
"Transaction manager does not allow nested transactions by default - " +
"specify 'nestedTransactionAllowed' property with value 'true'");
}
if (debugEnabled) {
logger.debug("Creating nested transaction with name [" + definition.getName() + "]");
}
if (useSavepointForNestedTransaction()) {
// Create savepoint within existing Spring-managed transaction,
// through the SavepointManager API implemented by TransactionStatus.
// Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.
DefaultTransactionStatus status =
newTransactionStatus(definition, transaction, false, false, debugEnabled, null);
status.createAndHoldSavepoint();
return status;
}
else {
// Nested transaction through nested begin and commit/rollback calls.
// Usually only for JTA: Spring synchronization might get activated here
// in case of a pre-existing JTA transaction.
doBegin(transaction, definition);
boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);
}
}
// Assumably PROPAGATION_SUPPORTS.
if (debugEnabled) {
logger.debug("Participating in existing transaction");
}
boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
return newTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);
}
我們看到這個方法其實很明了，就是什麼樣的傳播途徑就創建什麼樣的 transactionstatus，這個方法是在事務開始時被調用的，拿到我們之前舉的例子中來看 下，我們就恍然大悟了，原來，如果之前已經創建過事務，那個這個新建的 transactionstauts就不應該是屬於一個newTransaction了，所以第3個參數就是false了 。
也就是說，在BService的方法出棧要要執行processcommit，但是由於BService的那個 TransactionStatus不是一個newTransaction，所以它根本不會觸發這個動作：
Java代碼
else if (status.isNewTransaction()) {//這個判斷非常重要，下面會詳細講 解這個判斷的作用
if (status.isDebug()) {
logger.debug("Initiating transaction commit");
}
boolean globalRollbackOnly = status.isGlobalRollbackOnly();
doCommit(status);
}
也就是說在BService的方法出棧後，事務是不會提交的。這完全符合 propragation_required的模型。
而在AService的方法出棧後，AService的方法所對應的那個TransactionStatus對象的 newTransaction屬性是為true的，即它會觸發上面這段代碼，進行真正的事務提交。讓我 們回想一下AService方法入棧之前創建TransactionStatus對象的情形吧：
newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);看到第3個參數為true沒有。
那麼事務該提交了吧，事務的提交我想使用過hibernate的人都知道怎麼提交了：
txObject.getSessionHolder().getTransaction().commit();
從當前線程中拿到SessionHolder，再拿到開始事務的那個Transaction對象，然後再 commit事務。在沒有用spring之前，我們經常這麼做。呵呵。
好吧，我已經說到了spring聲明式事務管理的70%到80%的內容了，這70%到80%的內容 看上去還是非常容易理解的，如果把這兩篇文章認真看過，我相信會有所收獲的，剩下的 內容需要靠大家自己去挖掘了，因為另剩下的內容可是需要花費很多時間的，因為牽扯的 東西實在是太多了，呵呵。最後祝大家閱讀愉快，因為我的文筆實在是讓大家的眼睛受罪 了。
