aspose file tools*
The moose likes Object Relational Mapping and the fly likes JPA: pessimistic locking etc. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA: pessimistic locking etc." Watch "JPA: pessimistic locking etc." New topic
Author

JPA: pessimistic locking etc.

Antero Laukkanen
Greenhorn

Joined: Aug 24, 2007
Posts: 6
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.
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
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.


-Mike
Pro JPA 2: Mastering the Java Persistence API
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JPA: pessimistic locking etc.