簡(jiǎn)介:上次說(shuō)到spring聲明式事務(wù)管理的事務(wù)開(kāi)始部分,按流程來(lái)講,下面應(yīng)該提交事務(wù)了, spring的聲明式事務(wù)管理其實(shí)是比較復(fù)雜的,事實(shí)上這種復(fù)雜性正是由于事務(wù)本身的復(fù)雜性導(dǎo)致的,如果能用兩三句話(huà)就把這部分內(nèi)容說(shuō)清楚是不現(xiàn)實(shí)的,也是不成熟的,而我對(duì)這部分的理解也可能是不全面的,還是那句話(huà),希望大家和我一起把本貼的質(zhì)量提交起來(lái)。
在下面的文章中,我講會(huì)多次提到第一篇文章,第一篇文章的地址是:
http://www.javaeye.com/topic/87426
如果要理解事務(wù)提交的話(huà),理解事務(wù)開(kāi)始是一個(gè)前提條件,所以請(qǐng)先看第一篇文章,再來(lái)看這篇
如果你仔細(xì)看下去,我想肯定是有很多收獲,因?yàn)槲覀兇_實(shí)能從spring的代碼和思想中學(xué)到很多東西。
正文:
其實(shí)俺的感覺(jué)就是事務(wù)提交要比事務(wù)開(kāi)始復(fù)雜,看事務(wù)是否提交我們還是要回到TransactionInterceptor類(lèi)的invoke方法
- public Object invoke(MethodInvocation invocation) throws Throwable {
-
-
-
- Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;
-
-
- TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod(), targetClass);
-
- Object retVal = null;
- try {
-
-
-
- retVal = invocation.proceed();
- }
- catch (Throwable ex) {
-
- doCloseTransactionAfterThrowing(txInfo, ex);
- throw ex;
- }
- finally {
- doFinally(txInfo);
- }
- doCommitTransactionAfterReturning(txInfo);
- return retVal;
- }
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);//業(yè)務(wù)方法出棧后必須先執(zhí)行的一個(gè)方法
}
doCommitTransactionAfterReturning(txInfo);
return retVal;
}
其中的doFinally(txInfo)那一行很重要,也就是說(shuō)不管如何,這個(gè)doFinally方法都是要被調(diào)用的,為什么它這么重要呢,舉個(gè)例子:
我們還是以propregation_required來(lái)舉例子吧,假設(shè)情況是這樣的,AService中有一個(gè)方法調(diào)用了BService中的,這兩個(gè)方法都處在事務(wù)體之中,他們的傳播途徑都是required。那么調(diào)用開(kāi)始了,AService的方法首先入方法棧,并創(chuàng)建了TransactionInfo的實(shí)例,接著B(niǎo)Service的方法入棧,又創(chuàng)建了一個(gè)TransactionInfo的實(shí)例,而重點(diǎn)要說(shuō)明的是TransactionInfo是一個(gè)自身關(guān)聯(lián)的內(nèi)部類(lè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è)方法吧:
- protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
-
-
-
- txInfo.bindToThread();
- return txInfo;
- }
-
- 就是這個(gè)bindToThread()方法在作怪:
- private void bindToThread() {
-
-
- oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get();
- currentTransactionInfo.set(this);
- }
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)前線(xiàn)程中已經(jīng)有了一個(gè)TransactionInfo,則拿出來(lái)放到新建的transactionInfo對(duì)象的oldTransactionInfo屬性中,然后再把新建的TransactionInfo設(shè)置到當(dāng)前線(xiàn)程中。
這里有一個(gè)概念要搞清楚,就是TransactionInfo對(duì)象并不是表明事務(wù)狀態(tài)的對(duì)象,表明事務(wù)狀態(tài)的對(duì)象是TransactionStatus對(duì)象,這個(gè)對(duì)象同樣是TransactionInfo的一個(gè)屬性(這一點(diǎn),我在前面一篇文章中并沒(méi)有講清楚)。
接下來(lái)BService中的那個(gè)方法返回,那么該它退棧了,它退棧后要做的就是doFinally方法,即把它的oldTransactionInfo設(shè)置到當(dāng)前線(xiàn)程中(這個(gè)TransactionInfo對(duì)象顯然就是AService方法入棧時(shí)創(chuàng)建的,怎么現(xiàn)在又要設(shè)置到線(xiàn)程中去呢,原因就是BService的方法出棧時(shí)并不提交事務(wù),因?yàn)锽Service的傳播途徑是required,所以要把棧頂?shù)姆椒ㄋ鶆?chuàng)建transactioninfo給設(shè)置到當(dāng)前線(xiàn)程中),即調(diào)用AService的方法時(shí)所創(chuàng)建的TransactionInfo對(duì)象。那么在AServie的方法出棧時(shí)同樣會(huì)設(shè)置TransactionInfo對(duì)象的oldTransactionInfo到當(dāng)前線(xiàn)程,這時(shí)候顯然oldTransactionInfo是空的,但AService中的方法會(huì)提交事務(wù),所以它的oldTransactionInfo也應(yīng)該是空了。
在這個(gè)小插曲之后,么接下來(lái)就應(yīng)該是到提交事務(wù)了,之前在AService的方法出棧時(shí),我們拿到了它入棧時(shí)創(chuàng)建的TransactionInfo對(duì)象,這個(gè)對(duì)象中包含了AService的方法事務(wù)狀態(tài)。即TransactionStatus對(duì)象,很顯然,太顯然了,事務(wù)提交中的任何屬性都和事務(wù)開(kāi)始時(shí)的創(chuàng)建的對(duì)象息息相關(guān),這個(gè)TransactionStatus對(duì)象哪里來(lái)的,我們?cè)倩仡^看看createTransactionIfNessary方法吧:
- protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
- txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
- }
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
}
再看看transactionManager.getTransaction(txAttr)方法吧:
- 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);
- }
- }
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);//注意這里的返回值,返回的就是一個(gè)TransactionStatus對(duì)象,這個(gè)對(duì)象表明了一個(gè)事務(wù)的狀態(tài),比如說(shuō)是否是一個(gè)新的事務(wù),事務(wù)是否已經(jīng)結(jié)束,等等,這個(gè)對(duì)象是非常重要的,在事務(wù)提交的時(shí)候還是會(huì)用到它的。 }
}
}
還有一點(diǎn)需要說(shuō)明的是,AService的方法在執(zhí)行之前創(chuàng)建的transactionstatus確實(shí)是通過(guò)這個(gè)方法創(chuàng)建的,但是,BService的方法在執(zhí)行之前創(chuàng)建transactionstatus的方法就與這個(gè)不一樣了,下面會(huì)有詳解。
回顧了事務(wù)開(kāi)始時(shí)所調(diào)用的方法之后,是不是覺(jué)得現(xiàn)在對(duì)spring如何處理事務(wù)越來(lái)越清晰了呢。由于這么幾個(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ù),釋放資源的,讓我們來(lái)看看TransactionInterceptor的invoke的最后那個(gè)方法doCommitTransactionAfterReturning:
- 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());
-
- }
- }
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());
//瞧:提交事務(wù)時(shí)用到了表明事務(wù)狀態(tài)的那個(gè)TransactionStatus對(duì)象了。
}
}
看這個(gè)方法的名字就知道spring是要在業(yè)務(wù)方法出棧時(shí)提交事務(wù),貌似很簡(jiǎn)單,但是事實(shí)是這樣的嗎? 我們接著往下看。
- 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);
- }
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,但是看上去,它又把自己的職責(zé)分配給別人了,從代碼里我們看到,如果事務(wù)已經(jīng)結(jié)束了就拋異常,如果事務(wù)是rollbackonly的,那么就rollback吧,但是按照正常流程,我們還是想來(lái)看一下,事務(wù)的提交,就是processCommit(status)這個(gè)方法吧。
- 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);
-
-
- `````````````````````
- }
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()) {//這個(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ù),下面這段話(huà)就非常重要了,BService的中的方法是先出棧的,也就是說(shuō)在調(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只不過(guò)是一個(gè)輔助類(lèi)而已,用來(lái)記錄一系列狀態(tài)的輔助類(lèi))的TransactionStatus的時(shí)候就會(huì)進(jìn)入下面這個(gè)方法(當(dāng)然在這之前會(huì)判斷一下當(dāng)前線(xiàn)程中是否已經(jīng)有了一個(gè)SessionHolder對(duì)象,不清楚SessionHolder作用的同學(xué)情況第一篇文章),這個(gè)方法其實(shí)應(yīng)該放到第一篇文章中講的,但是想到如果不講事務(wù)提交就講這個(gè)方法好像沒(méi)有這么貼切,廢話(huà)少說(shuō),我們來(lái)看一下吧:
- 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()) {
-
-
-
- DefaultTransactionStatus status =
- newTransactionStatus(definition, transaction, false, false, debugEnabled, null);
- status.createAndHoldSavepoint();
- return status;
- }
- else {
-
-
-
- doBegin(transaction, definition);
- boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
- return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);
- }
- }
-
-
- if (debugEnabled) {
- logger.debug("Participating in existing transaction");
- }
- boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
- return newTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null);
- }
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);
}
我們看到這個(gè)方法其實(shí)很明了,就是什么樣的傳播途徑就創(chuàng)建什么樣的transactionstatus,這個(gè)方法是在事務(wù)開(kāi)始時(shí)被調(diào)用的,拿到我們之前舉的例子中來(lái)看下,我們就恍然大悟了,原來(lái),如果之前已經(jīng)創(chuàng)建過(guò)事務(wù),那個(gè)這個(gè)新建的transactionstauts就不應(yīng)該是屬于一個(gè)newTransaction了,所以第3個(gè)參數(shù)就是false了。
也就是說(shuō),在BService的方法出棧要要執(zhí)行processcommit,但是由于BService的那個(gè)TransactionStatus不是一個(gè)newTransaction,所以它根本不會(huì)觸發(fā)這個(gè)動(dòng)作:
- else if (status.isNewTransaction()) {
- if (status.isDebug()) {
- logger.debug("Initiating transaction commit");
- }
- boolean globalRollbackOnly = status.isGlobalRollbackOnly();
- doCommit(status);
- }
else if (status.isNewTransaction()) {//這個(gè)判斷非常重要,下面會(huì)詳細(xì)講解這個(gè)判斷的作用
if (status.isDebug()) {
logger.debug("Initiating transaction commit");
}
boolean globalRollbackOnly = status.isGlobalRollbackOnly();
doCommit(status);
}
也就是說(shuō)在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, debugEnabled, null);看到第3個(gè)參數(shù)為true沒(méi)有。
那么事務(wù)該提交了吧,事務(wù)的提交我想使用過(guò)hibernate的人都知道怎么提交了:
txObject.getSessionHolder().getTransaction().commit();
從當(dāng)前線(xiàn)程中拿到SessionHolder,再拿到開(kāi)始事務(wù)的那個(gè)Transaction對(duì)象,然后再commit事務(wù)。在沒(méi)有用spring之前,我們經(jīng)常這么做。呵呵。
好吧,我已經(jīng)說(shuō)到了spring聲明式事務(wù)管理的70%到80%的內(nèi)容了,這70%到80%的內(nèi)容看上去還是非常容易理解的,如果把這兩篇文章認(rèn)真看過(guò),我相信會(huì)有所收獲的,剩下的內(nèi)容需要靠大家自己去挖掘了,因?yàn)榱硎O碌膬?nèi)容可是需要花費(fèi)很多時(shí)間的,因?yàn)闋砍兜臇|西實(shí)在是太多了,呵呵。最后祝大家閱讀愉快,因?yàn)槲业奈墓P實(shí)在是讓大家的眼睛受罪了。