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.
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.