• 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
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Entity Manager Life Cycle  RSS feed

Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Ranch Hand
Posts: 553
Carlos Conti
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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,


It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!