aspose file tools*
The moose likes Spring and the fly likes Transaction rollback in a multithreaded scenario Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Frameworks » Spring
Bookmark "Transaction rollback in a multithreaded scenario" Watch "Transaction rollback in a multithreaded scenario" New topic
Author

Transaction rollback in a multithreaded scenario

Hema Nandhini
Ranch Hand

Joined: Aug 04, 2008
Posts: 31
Hi all,

I am new to Spring transaction management. My business requirement is this:

I have a method, say updateData in dao layer. This method will do series of postgres operations and return a map which will hold status, errorcode, errormessage as keys and appropriate values for them. When there is huge data input , I want to split the input data and execute this method[updateData] in different threads. Even if one thread fails all other threads also should rollback. Currently only the thread which fails is rolled back. All other threads are getting committed. Can someone help me how to manage the transaction for this multithreaded scenario.

This is my code setup:
1. I use annotation-driven transaction management for updateData [@Transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)]. Code looks something like this:


2. I use ExecutorService to spawn threads and get the Future objects to check for the results. Code looks something like


3. I use org.springframework.jdbc.core.JdbcTemplate and org.springframework.jdbc.datasource.DataSourceTransactionManager for executing queries. For example, like this:
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

My initial reaction is that the transaction annotations are going to use a different session for each transaction--is there a way to find out?

If you're able to use JTA, that might not matter: you'd start a "meta-transaction" in the spawning thread, each thread would do its own nested transaction, then the spawning thread would commit the over-arching transaction when each thread was done. If the spawning thread is non-blocking (i.e., fire-and-forget the threads), you'd probably need to spawn a thread that spawns the DB threads and commit the master transaction there.

Don't know if that'll help at all, but if I were exploring this problem, I'd start with that. Hopefully someone else will have a better idea!
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29230
    
135

Hema,
I think you would have to write some code (programmatic transaction management) to do this. Spring isn't going to have any way of knowing when to commit.

While the manual covers the helper class for programmatic transactions, most of the work is writing the custom logic.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29230
    
135

David Newton wrote:If you're able to use JTA, that might not matter: you'd start a "meta-transaction" in the spawning thread, each thread would do its own nested transaction, then the spawning thread would commit the over-arching transaction when each thread was done. If the spawning thread is non-blocking (i.e., fire-and-forget the threads), you'd probably need to spawn a thread that spawns the DB threads and commit the master transaction there.

This is a good point. If the caller "joins" all the threads at the end, something does know when it is done.
Hema Nandhini
Ranch Hand

Joined: Aug 04, 2008
Posts: 31
Thanks a lot for your replies. I tried spawning the threads inside programatic transaction ie., transactionTemplate and did the status.setRollBackOnly() flag when any one of the threads fail. But this does not help. Even the thread that fails doesnt rollback....
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

What I'm saying is that each thread probably has its own session, hence own tx. This means you need to nest your transactions using something like JTA (there may be other solutions).
Hema Nandhini
Ranch Hand

Joined: Aug 04, 2008
Posts: 31
Sorry about it. My application is deployed to Tomcat 6. I believe we cannot use JTA transaction manager in tomcat.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

There are JTA implemetnations available.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Transaction rollback in a multithreaded scenario
 
Similar Threads
Old Issue, but not finding a solution: org.hibernate.LazyInitializationException
Can a MailSender participate in a transaction?
javamail: method blocks instead of throwing exception
Please Help....NullPointerException...
rollback for checked exceptions as default