• 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

JPA: pessimistic locking etc.

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have a system that processes these events that it receives. The system could be processing several different events at a time in parallel. Processing of these events results in db updates and will need to make sure these updates don't cause StaleStateExceptions.

I was thinking I'd have one session for each client and keep it always open as long as there are events from that client that are being processed. Then, I'd use synchronized blocks to somehow make sure the updates don't fail.

Got a bunch of questions though I'd like to see someone answer for me..

-I understand JPA doesn't really help me much if I want there to be pessimistic locking to avoid conflicting modifications?

-Is the best (only) way to deal with this simply to lock on some common object in all the places in the code where running the code could otherwise result in conflicting updates?

// this bit in all places where user's data could change..
synchronized (userWhosDataCouldChange) {
// code that could update the users data..
}

-Or will I need to synchronize on the entitymanager even if it is ever more likely a real performance killer..?

-Any suggestions about useful patterns in general for this type of applications? Think it might be a good idea to have a (quite huge?) facade for all the methods that I need to make safe from StaleStateExceptions? All the synchronization could then at least happen in one place.

-Putting everything into a facade might not make much sense if I need to synchronize on the entitymanager..? I'm worried the facade get's filled with quite a few methods. Any ideas about useful patterns would be helpful really, haven't really figured out anything I particularly like..

I've tried to do some research on these issues without a real breakthrough. Some of the ideas I explained I was thinking about can at least loosely be linked with some of the stuff that has been discussed at http://www.hibernate.org/333.html , but wasn't really sure how all they're saying there applies here so I thought I'd see if anyone here would be kind enough to share any thoughts on any of my questions..

Thanks for reading.
 
author
Posts: 304
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You might want to read up on optimistic locking. It is supported by JPA and is a much better alternative when the possibility of collision is relatively small. It means that you have to have retry logic in your application, but the performance is far better than pessimistic locking, which is really unnecessary anyway for the type of application that you seem to be talking about.
 
reply
    Bookmark Topic Watch Topic
  • New Topic