• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Transaction rollback in a multithreaded scenario

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry about it. My application is deployed to Tomcat 6. I believe we cannot use JTA transaction manager in tomcat.
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are JTA implemetnations available.
 
reply
    Bookmark Topic Watch Topic
  • New Topic