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.