In order to make hibernate do the Optimistic Locking we are setting the optimistic-lock="version" and the <timestamp> attribute in the configuration xml (cfg.xml).

If there is an optimistic-lock value set and when user tries to modify and save a record, in the update statement generated by hibernate, it will put a where clause with the timestamp column (column name mentioned in the <timestamp> attribute) and the primary key condition.

During the initial load of that record, hibernate stores this timestamp value somewhere in its memory and retrieves it back to add it to the where clause of the update statement.

If the update was successful, JDBC call returns the affected record count.

If the update was not successful, JDBC call returns 0 and hibernate throws a StaleObjectStateException.

Possible reason could be not finding a suitable match as mentioned in the where clause.

By writing an Interceptor class, on load of a record, we could see the value for last_update_date as,

The value coming in POJO is --> 2007-02-19 18:09:20.187119

Actual value in Database is --> 2007-2-19 18.9.20.187119000 -6:0

In database, the last_update_date is TIMESTAMP WITH TIMEZONE where as in POJO it is only TIMESTAMP.

When tried converting the java.sql.timestamp value in POJO to java.util.date, then we see the following output.

Converted to java.util.date --> Mon Feb 19 18:09:20 GMT+05:30 2007

Since the time zone details wasn’t there in the POJO field; when converted to date, it picked up the Virtual Machines default time zone.

Assuming that because of this the where clause is failing and hibernate is saying that the record is stale.

Can somebody please help me figure out a solution for this problem?
Please revert back If you need more inputs.

Your help is really appreiated.
Sajesh

What database are you using. According to this: <http://www.hibernate.org/80.html>

"At least some versions of the Oracle 9i driver handle JDBC timestamps extremely badly - do not use timestamps for optimistic locking, use version numbers."