Menu
▾
▴
springframework-developer
|
From: Andy D. <an...@ma...> - 2005-06-24 01:06:52
|
I've discovered that Spring's PlatformTransactionManager (JTA version in my case) will *always* invoke TransactionSynchronizations when its commit() method is called, even if it is participating in a pre-existing JTA transaction. Is this expected behavior? PlatformTransactionManager's JavaDoc for its "commit" method says, "If the transaction wasn't a new one, omit the commit for proper participation in the surrounding transaction." Which AbstractPlatformTransactionManager does indeed honor - however, it will still call any Spring TransactionSynchronizations against the transaction, as if a commit had been performed anyway. In my case, 3rd party code has started a JTA transaction (not using Spring) and then invoked my Spring based code. My Spring based code relies entirely on Spring for transaction management, and I use TransactionInterceptor around my business interfaces. TranactionInterceptor invokes PlatformTransactionManager, which joins in the already existing JTA transaction (things are going well so far). My code then registers a TransactionSynchronization, assuming that when "afterCompletion" is called on the synchronization that the transaction has been safely committed. However, once my business method exits, TransactionInterceptor will call commit() on PlatformTransactionManager which behaves well and does *not* tell JTA to commit since it had joined an already existing transaction. However, afterCompletion *is* called at this point on my TransactionSynchronization, causing my code to update an external resource as if the transaction is safely committed. However, the actual JTA transaction is still outstanding. What happens in my case is that sometimes the transaction will be rolled back by the 3rd party code, and not only is my TransactionSynchronization never notified, but it also already committed (now invalid) information to an external resource. Based on the description of TransactionSynchronization in Spring, it would seem like a safe assumption that the methods contained therein should track the actual transaction and not just Spring's participation in that transaction. Is this not true? - Andy |
|
From: Juergen H. <ju...@in...> - 2005-06-24 15:26:33
|
Indeed, in case of an existing JTA transaction, we should try to register with the JTA TransactionManager and at least synchronize the "afterCompletion" callback (which receives a transaction status - committed or rolled back) with the outer transaction. I've just reworked AbstractPlatformTransactionManager and JtaTransactionManager accordingly, registering a corresponding JTA Synchronization if the JTA TransactionManager is available. Else, it will still call "afterCompletion" immediately at completion of the Spring transaction demarcation, but pass in "STATUS_UNKNOWN" now, as we effectively don't know whether the outer JTA transaction is gonna commit or roll back. This will be shipped in Spring 1.2.2, to be released tonight. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Andy Depue Sent: Friday, June 24, 2005 3:06 AM To: spr...@li... Subject: [Springframework-developer] TransactionSynchronization invoked even when participating in existing transaction I've discovered that Spring's PlatformTransactionManager (JTA version in my case) will *always* invoke TransactionSynchronizations when its commit() method is called, even if it is participating in a pre-existing JTA transaction. Is this expected behavior? PlatformTransactionManager's JavaDoc for its "commit" method says, "If the transaction wasn't a new one, omit the commit for proper participation in the surrounding transaction." Which AbstractPlatformTransactionManager does indeed honor - however, it will still call any Spring TransactionSynchronizations against the transaction, as if a commit had been performed anyway. In my case, 3rd party code has started a JTA transaction (not using Spring) and then invoked my Spring based code. My Spring based code relies entirely on Spring for transaction management, and I use TransactionInterceptor around my business interfaces. TranactionInterceptor invokes PlatformTransactionManager, which joins in the already existing JTA transaction (things are going well so far). My code then registers a TransactionSynchronization, assuming that when "afterCompletion" is called on the synchronization that the transaction has been safely committed. However, once my business method exits, TransactionInterceptor will call commit() on PlatformTransactionManager which behaves well and does *not* tell JTA to commit since it had joined an already existing transaction. However, afterCompletion *is* called at this point on my TransactionSynchronization, causing my code to update an external resource as if the transaction is safely committed. However, the actual JTA transaction is still outstanding. What happens in my case is that sometimes the transaction will be rolled back by the 3rd party code, and not only is my TransactionSynchronization never notified, but it also already committed (now invalid) information to an external resource. Based on the description of TransactionSynchronization in Spring, it would seem like a safe assumption that the methods contained therein should track the actual transaction and not just Spring's participation in that transaction. Is this not true? - Andy ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Andy D. <an...@ma...> - 2005-06-24 15:42:03
|
Wow, this is great response time! This has become quite an issue for us, and it looks like this should solve the issue nicely. Thanks, Andy On Friday 24 June 2005 08:26 am, Juergen Hoeller wrote: > Indeed, in case of an existing JTA transaction, we should try to register > with the JTA TransactionManager and at least synchronize the > "afterCompletion" callback (which receives a transaction status - committed > or rolled back) with the outer transaction. > > I've just reworked AbstractPlatformTransactionManager and > JtaTransactionManager accordingly, registering a corresponding JTA > Synchronization if the JTA TransactionManager is available. Else, it will > still call "afterCompletion" immediately at completion of the Spring > transaction demarcation, but pass in "STATUS_UNKNOWN" now, as we > effectively don't know whether the outer JTA transaction is gonna commit or > roll back. > > This will be shipped in Spring 1.2.2, to be released tonight. > > Juergen |
