Spring聲明式事務(wù)管理源碼解讀之事務(wù)提交
相關(guān)文章:Spring聲明式事務(wù)管理源碼解讀之事務(wù)開始
其實(shí)我的感覺就是事務(wù)提交要比事務(wù)開始復(fù)雜,看事務(wù)是否提交我們還是要回到TransactionInterceptor類的invoke方法:
Java代碼
public Object invoke(MethodInvocation invocation) throws Throwable {
// Work out the target class: may be null.
// 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);//業(yè)務(wù)方法出棧后必須先執(zhí)行的一個(gè)方法
}
doCommitTransactionAfterReturning(txInfo);
return retVal;
}
其中的doFinally(txInfo)那一行很重要,也就是說不管如何,這個(gè)doFinally方法都是要被調(diào)用的,為什么它這么重要呢,舉個(gè)例子:
我們還是以propregation_required來舉例子吧,假設(shè)情況是這樣的,AService中有一個(gè)方法調(diào)用了BService中的,這兩個(gè)方法都處在事務(wù)體之中,他們的傳播途徑都是required。那么調(diào)用開始了,AService的方法首先入方法棧,并創(chuàng)建了TransactionInfo的實(shí)例,接著BService的方法入棧,又創(chuàng)建了一個(gè)TransactionInfo的實(shí)例,而重點(diǎn)要說明的是TransactionInfo是一個(gè)自身關(guān)聯(lián)的內(nèi)部類,第二個(gè)方法入棧時(shí),會(huì)給新創(chuàng)建的TransactionInfo的實(shí)例設(shè)置一個(gè)屬性,就是TransactionInfo對(duì)象中的private TransactionInfo oldTransactionInfo;屬性,這個(gè)屬性表明BService方法的創(chuàng)建的TransactionInfo對(duì)象是有一個(gè)old的transactionInfo對(duì)象的,這個(gè)oldTransactionInfo對(duì)象就是AService方法入棧時(shí)創(chuàng)建的TransactionInfo對(duì)象,我們還記得在createTransactionIfNecessary方法里有這樣一個(gè)方法吧:
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;
}
就是這個(gè)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);
}
|
如果當(dāng)前線程中已經(jīng)有了一個(gè)TransactionInfo,則拿出來放到新建的transactionInfo對(duì)象的oldTransactionInfo屬性中,然后再把新建的TransactionInfo設(shè)置到當(dāng)前線程中。
這里有一個(gè)概念要搞清楚,就是TransactionInfo對(duì)象并不是表明事務(wù)狀態(tài)的對(duì)象,表明事務(wù)狀態(tài)的對(duì)象是TransactionStatus對(duì)象,這個(gè)對(duì)象同樣是TransactionInfo的一個(gè)屬性。
接下來BService中的那個(gè)方法返回,那么該它退棧了,它退棧后要做的就是doFinally方法,即把它的oldTransactionInfo設(shè)置到當(dāng)前線程中(這個(gè)TransactionInfo對(duì)象顯然就是AService方法入棧時(shí)創(chuàng)建的,怎么現(xiàn)在又要設(shè)置到線程中去呢,原因就是BService的方法出棧時(shí)并不提交事務(wù),因?yàn)锽Service的傳播途徑是required,所以要把棧頂?shù)姆椒ㄋ鶆?chuàng)建transactioninfo給設(shè)置到當(dāng)前線程中),即調(diào)用AService的方法時(shí)所創(chuàng)建的TransactionInfo對(duì)象。那么在AServie的方法出棧時(shí)同樣會(huì)設(shè)置TransactionInfo對(duì)象的oldTransactionInfo到當(dāng)前線程,這時(shí)候顯然oldTransactionInfo是空的,但AService中的方法會(huì)提交事務(wù),所以它的oldTransactionInfo也應(yīng)該是空了。
在這個(gè)小插曲之后,接下來就應(yīng)該是到提交事務(wù)了,之前在AService的方法出棧時(shí),我們拿到了它入棧時(shí)創(chuàng)建的TransactionInfo對(duì)象,這個(gè)對(duì)象中包含了AService的方法事務(wù)狀態(tài)。即TransactionStatus對(duì)象,很顯然,太顯然了,事務(wù)提交中的任何屬性都和事務(wù)開始時(shí)的創(chuàng)建的對(duì)象息息相關(guān),這個(gè)TransactionStatus對(duì)象哪里來的,我們?cè)倩仡^看看createTransactionIfNessary方法吧:
Java代碼
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) { |
再看看transactionManager.getTransaction(txAttr)方法吧:
Java代碼
public final TransactionStatus getTransaction(TransactionDefinition definition) |
#p#
還有一點(diǎn)需要說明的是,AService的方法在執(zhí)行之前創(chuàng)建的transactionstatus確實(shí)是通過這個(gè)方法創(chuàng)建的,但是,BService的方法在執(zhí)行之前創(chuàng)建transactionstatus的方法就與這個(gè)不一樣了,下面會(huì)有詳解。
回顧了事務(wù)開始時(shí)所調(diào)用的方法之后,是不是覺得現(xiàn)在對(duì)spring如何處理事務(wù)越來越清晰了呢。由于這么幾個(gè)方法的調(diào)用,每個(gè)方法入棧之前它的事務(wù)狀態(tài)就已經(jīng)被設(shè)置好了。這個(gè)事務(wù)狀態(tài)就是為了在方法出棧時(shí)被調(diào)用而準(zhǔn)備的。
讓我們?cè)俅位氐紹Service中的方法出棧的那個(gè)時(shí)間段,看看spring都做了些什么,我們知道,后入棧的肯定是先出棧,BService中的方法后入棧,那它肯定要先出棧了,它出棧的時(shí)候是要判斷是否要提交事務(wù),釋放資源的,讓我們來看看TransactionInterceptor的invoke的***那個(gè)方法doCommitTransactionAfterReturning:
Java代碼
protected void doCommitTransactionAfterReturning(TransactionInfo txInfo) { |
看這個(gè)方法的名字就知道spring是要在業(yè)務(wù)方法出棧時(shí)提交事務(wù),貌似很簡(jiǎn)單,但是事實(shí)是這樣的嗎?我們接著往下看。
Java代碼
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,但是看上去,它又把自己的職責(zé)分配給別人了,從代碼里我們看到,如果事務(wù)已經(jīng)結(jié)束了就拋異常,如果事務(wù)是rollbackonly的,那么就rollback吧,但是按照正常流程,我們還是想來看一下,事務(wù)的提交,就是processCommit(status)這個(gè)方法吧。
Java代碼
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()) {//這個(gè)判斷非常重要,下面會(huì)詳細(xì)講解這個(gè)判斷的作用
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.
`````````````````````
}
我們注意到,在判斷一個(gè)事務(wù)是否是新事務(wù)之前還有一個(gè)status.hasSavepoint()的判斷,我認(rèn)為這個(gè)判斷事實(shí)上就是嵌套事務(wù)的判斷,即判斷這個(gè)事務(wù)是否是嵌套事務(wù),如果不是嵌套事務(wù),則再判斷它是否是一個(gè)新事務(wù),下面這段話就非常重要了,BService的中的方法是先出棧的,也就是說在調(diào)用BService之前的創(chuàng)建的那個(gè)事務(wù)狀態(tài)對(duì)象在這里要先被判斷,但是由于在調(diào)用BService的方法之前已經(jīng)創(chuàng)建了一個(gè)Transaction和Session(假設(shè)我們使用的是hibernate3),這時(shí)候在創(chuàng)建第二個(gè)TransactionInfo(再?gòu)?qiáng)調(diào)一下吧,TransactionInfo并不是Transaction,Transaction是真正的事務(wù)對(duì)象,TransactionInfo只不過是一個(gè)輔助類而已,用來記錄一系列狀態(tài)的輔助類)的TransactionStatus的時(shí)候就會(huì)進(jìn)入下面這個(gè)方法(當(dāng)然在這之前會(huì)判斷一下當(dāng)前線程中是否已經(jīng)有了一個(gè)SessionHolder對(duì)象,不清楚SessionHolder作用的同學(xué)請(qǐng)看***篇文章):
Java代碼
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);
}
我們看到這個(gè)方法其實(shí)很明了,就是什么樣的傳播途徑就創(chuàng)建什么樣的transactionstatus,這個(gè)方法是在事務(wù)開始時(shí)被調(diào)用的,拿到我們之前舉的例子中來看下,我們就恍然大悟了,原來,如果之前已經(jīng)創(chuàng)建過事務(wù),那個(gè)這個(gè)新建的transactionstauts就不應(yīng)該是屬于一個(gè)newTransaction了,所以第3個(gè)參數(shù)就是false了。
也就是說,在BService的方法出棧要要執(zhí)行processcommit,但是由于BService的那個(gè)TransactionStatus不是一個(gè)newTransaction,所以它根本不會(huì)觸發(fā)這個(gè)動(dòng)作:
Java代碼
else if (status.isNewTransaction()) {//這個(gè)判斷非常重要,下面會(huì)詳細(xì)講解這個(gè)判斷的作用 |
也就是說在BService的方法出棧后,事務(wù)是不會(huì)提交的。這完全符合propragation_required的模型。
而在AService的方法出棧后,AService的方法所對(duì)應(yīng)的那個(gè)TransactionStatus對(duì)象的newTransaction屬性是為true的,即它會(huì)觸發(fā)上面這段代碼,進(jìn)行真正的事務(wù)提交。讓我們回想一下AService方法入棧之前創(chuàng)建TransactionStatus對(duì)象的情形吧:
newTransactionStatus(definition, transaction, true, newSynchronization, debu |
看到第3個(gè)參數(shù)為true沒有。
那么事務(wù)該提交了吧,事務(wù)的提交我想使用過hibernate的人都知道怎么提交了:
txObject.getSessionHolder().getTransaction().commit(); |
從當(dāng)前線程中拿到SessionHolder,再拿到開始事務(wù)的那個(gè)Transaction對(duì)象,然后再commit事務(wù)。在沒有用spring之前,我們經(jīng)常這么做。
【編輯推薦】
























