The EJB spec says the following in section 3.4.2:



However, in a web application I am developing I have a need to update an entity with a version number posted from a web form. The form in question does not contain all the fields belonging to the entity, so my workflow is as follows:

1. Retrieve entity from database
2. Update the fields provided by the web form (including version)
3. Persist entity

As per the spec, Hibernate notes that the version is dirty and updates the entity with the version last seen in the database, so optimistic locking is ineffective. There are two ways around this that I can think of:

1. Include all the entities fields in the web form, and therefore avoid the need to retrieve the entity from the database in step 1 - just create the entity from the fields provided. This is not an option - it's not acceptable to make everything in the database available to a user via hidden form fields, especially when dealing with user accounts and other security related entities.
2. Detach the entity before persisting it to the database. This works perfectly, except that the JPA spec does not provide a means to detach a single entity, and detaching everything via em.clear() does not seem like a good solution in terms of the control you have, and possibly some performance implications.

Anybody else run across this scenario? Suggestions on how to handle this? I would be willing to move over to Hibernate annotations rather than using the JPA interface, if that provides the cleanest solution.

Thanks!

Hibernate version:
hibernate-core: 3.2.6.ga
hibernate-annotations: 3.3.1.GA
hibernate-commons-annotations: 3.0.0.ga
ejb3-persistence: 1.0.1.GA
hibernate-entitymanager: 3.3.2.GA

Hi,

why would you like to update the field used for optimistic locking?
If you need a version separate version field which is controlled by the application, why do you not just add another field? As you say yourself you are violating the spec by updating the version field manually.

--Hardy

Thanks for the reply. The version contained within the web form indicates the version of the entity that was shown to the user. If I do not update the version number in the entity according to what is in the form, all the optimistic lock is checking for is a modification to the data between when it retrieves the entity from the database, and when it is updated ... a very short space of time. It does not take into account the time between when the user loaded the page, made changes, and clicked the save button, which is a much longer period of time.

I came up with another idea on how to work around this. Well, if you want to call it a work around - maybe the writers of the spec would say I finally figured out my own problems. :-) Here is the work flow:

1. Retrieve entity from database.
2. Take note of version number of entity.
3. Entity updated with values from web form (Struts 2 interceptor)
4. Compare version of entity from database to version in web form. If they differ inform user of problem.
5. Merge entity to database.

Basically, I take care of optimistic locking during the user "think time", and let Hibernate take care of optimistic locking during the short time between when the entity is retrieved and when it is merged. It would be nice for Hibernate to do it all, but I'm sure they thought long and hard about this when writing the JPA spec, and had good reason to have it as it is.

Posting this as an answer to my own question for other people's edification. I have seen at least one other blog entry where this problem was pointed out as a deficiency of JPA, so maybe it will help others.