For session-per-request-with-detached-objects the only locking mechanism is with managed versioning. This means that legacy databases cannot be used with this type of session scope. Isn't that a huge drawback ? Couldn't it be solved easily with an extra (hidden) property in a POJO that represents the original state of it (for example a MD5 or CRC property) ?

Regards,

Sytze.

Hibernate version:
2.1.7
Mapping documents:
N/A
Code between sessionFactory.openSession() and session.close():
N/A
Full stack trace of any exception that occurs:
N/A
Name and version of the database you are using:
N/A
The generated SQL (show_sql=true):
N/A
Debug level Hibernate log excerpt:
N/A

Well if you can add a hidden MD5 field, you can also add a hidden version field.

AFAIK, the version field will be stored in the database. For legacy data, this is often not an option. What I mean, is a field that is not stored in the database, but calculated at retrieval and storage time from the data in the database. At storage time, the MD5 field of the POJO would be compared to the MD5 value calculated from the current data in the database.

This would not really help, because you need to know if the database was updated in the meantime, not if the pojo was updated in the meantime.

True. To detect changes in the database, one would calculate the MD5 value of the current data. If that value does not match with the MD5 from the POJO, the database had changed in the mean time. Which is still better than having no support for session p/request with detached object and legacy databases at all, I think.