On 13 Dec 2003 03:18, gavin wrote: >On 12 Dec 2003 20:34, vijpan wrote: >>In case of optimistic concurrency if you dont access the database how >>can you be sure that you are not trying to update the stale data? >Hibernate does a version number or timestamp check in the SQL UPDATE. >This is standard Hibernate functionality. Dear Gavin My comment on optimistic concurrency was referring to the solution# 1 provided in this article.I knew about this Hibernate functionality of version number or timestamp check. The author of the article stated the fact as below. 1)Hibernate added the select-before-update option in 2.1. Setting this option on your class will cause Hibernate to load the data from the database and compare that to the data in your object to determine what has changed. It makes use of a version or timestamp field to enforce optimistic concurrency. This works well but introduces additional database access that could effect performance. So with the hibernate facility there will be 2 calls for an update if we have (verion number or timestamp) set.Or the hibernate does that within 1 call i.e. if ther version number or timestamp doesnt match with the record in the database it gives back the error or else updates it. Whether Hibernate does it in 1 call or 2 calls we have to make sure that we are not writing over the stale data and for that there will be a call(1 or 2) to DB to check that.