Win a copy of Spark in Action this week in the Open Source Projects forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Rollback is not happening in Muti threaded environment

Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
not working in mutithreaded environment.Insert 2 schemas concurrently.

Used @Async, Future & ExecutorService for parallel DB operations.
If any one thread fails to update schema, entire transaction should rollback.
Currently it is not happening in Spring 3.1,XA,JTA and Weblogic 10.3.5

futures = es.invokeAll(callables);
for(Future<List<ResultDetails>> future : futures){
if (resultDetails.size() > 0) {
resultDetailsFuture = future;
Posts: 1682
Android Mac OS X IntelliJ IDE Spring Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer is much the same as reported in this thread:

Spring transactions are tied to the thread, this behavior is not going to happen with Spring transaction management. XA is for allowing multiple resources to participate in the transaction assuming we are talking about a single database here (or even if we are not) it is not relevant to this problem.

Now first question does this work even make sense to do in parallel? If not leave it in a single thread.

If it does an you are processing a lot of data and you want to chunk up that work, then maybe do the work in a multi threaded way and join all that work together and do the transaction part at the end in the calling thread.

Here is an example of what I am talking about. It might not be perfect I typed it free style here in the forum editor but it gives you an idea.

If you are bound and determined to do it the way you have been trying to, you have to drop Spring transaction management. You may be able to get it to work by passing the Connection object itself to each thread, but be careful. Transaction management, thread management, and exception handling would be your responsibility so make sure you understand what it is your doing. You would most likely still do a similar approach to the above but you would have to hold the connection open for a long time (generally a bad idea) until all of the big work is complete and then rollback all in the caller method if you encounter an error on any of them.

Its also important to note that though a Connection should be thread safe you should avoid sharing Connections between threads, since the activity on the connection will mean that only one thread will be able to do anything at a time, which defeats the purpose of what you are trying to do. In other words the connection is going to end up being a bottle neck.
I knew that guy would be trouble! Thanks tiny ad!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic