How does optimistic version locking work

Question

Hi,
I have below questions regarding toplink with optimistic version locking vs pessimistic locking after checking the developer guide:
in the guide, it suggests optimistic version locking oppose row level locking with select for update.
if use optimistic version locking, additional column is required in database for each table and it keeps version of each row via toplink, how does toplink keeps the version technically, does it have triiger or other procedure installed in DB for this tacking between DB and Apps cache? how does the version gets incremented and what is the max value for it?
if there are many rows in the table, how is the performance on the database level as each update statement need to verify the version of each record or it is all done on the apps cache?
Thanks.

Answer 1

It is quite simple
With optimistic locking you have extra column in database which transfer to another attribute in your object.
So when your application reads such object it has ID (primary key) and another attribute with version.
When you persist changes to object that attribute value (read when object was read from db) i added to query, so you have something like:
update xxxx set y = z,.... , version = version + 1 where id = <your obj id> and version = <current attribute value>
That way if another session updated such object your update won't work because there is no row in table with id and version of your object.
Assumption is that there is low concurrency and you are the only one editing that object (thats why its optimistic)
There is no max value for it other then database field limit. It is incremented at every update by adding that increase to sql send to db, so no trigger/procedure is needed.
As to performance - it is usually better then pessimistic locking but some of updates can fail, and since tables are accessed by primary key anyway additional condition for value shouldn't have much performance impact.