my dog learned polymorphism*
The moose likes Object Relational Mapping and the fly likes Entity Manager Life Cycle Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Entity Manager Life Cycle" Watch "Entity Manager Life Cycle" New topic
Author

Entity Manager Life Cycle

Carlos Conti
Ranch Hand

Joined: Apr 21, 2010
Posts: 114
Hi all,

I have some doubts about the safest way to use the entity manager on a multi-user environment.

I am programming a desktop application which in the future will be deployed to several client computers. Each running application will have its own entityManager instance running. The methods updating the database are synchronized (which is not important since the entitymanager is application contained). But I guess I should include some data locking functionality to prevent different users updating related data at the same time, running into risks of data corruption. The point is that I am not that experienced with JPA and ask for some light on the best approach to ensure that transactions from different users won't make data corrupt. Should I focus on the functionality provided in JPA for data locking, or would you recommend additional measures according to this deployment schema.

Regards and many thanks for your advise.

Carlos.
James Sutherland
Ranch Hand

Joined: Oct 01, 2007
Posts: 553
I would recommend optimistic version locking.

See,

http://en.wikibooks.org/wiki/Java_Persistence/Locking

TopLink : EclipseLink : Book:Java Persistence : Blog:Java Persistence Performance
Carlos Conti
Ranch Hand

Joined: Apr 21, 2010
Posts: 114
Hi James,

many thanks for your insights. As I conclude from the guide you addressed me, I should enclose the edited instance in a transaction which would begin from the moment I open the form to edit it, and commit it once I close the form. The Data Locking would be specified on an object basis via the @Version annotation and object member (long datatype). So the lifecycle you are suggesting would be:

I. Open the form
II. Begin a new Transaction upon Form initialisation
III. Obtain a reference to the edited instance via EntityManager.getObject(Class,Id) once being already inside the transaction
IV. Edit the object in the form
V. Persist the object
VI. Commit the transaction
VII. Close the transaction (I presume that by closing the transaction I release all database resources affected)
VIII. Close the form.

and done, isn't it?. Infact it wouldn't matter the at which point the transaction is opened, either before or after reading the object, as long as no changes are made to the object.

And from what I have understood, if a user attempted to edit an already being edited instance, this user could retrieve the instance, but wouldn't be able to write the changes back, until the transaction started from the other user was previously closed (OptimisticLockException), but once it was closed, the second user would be able to fire the changes.

Am I right?

If it is, it would be sufficient for my requirements.

thanks again and regards,

Carlos.

 
Consider Paul's rocket mass heater.
 
subject: Entity Manager Life Cycle