Re: Optimistic Locking

A timestamp cannot be guaranteed unique, especially on a multiprocessor machine. Use a sequence instead.

"Rauf Sarwar" <rs_arwar_at_hotmail.com> wrote in message news:92eeeff0.0305091057.5363f822_at_posting.google.com...
> "Jim Kennedy" <kennedy-down_with_spammers_at_attbi.com> wrote in message
 news:<XWDua.777782$3D1.426158_at_sccrnsc01>...
> > Or you include all the columns with the prior values in the where clause
 and
> > if you don't update a row then someone changed the data underneath you.
>
> Disadvantage of this is that you have to include all the columns (with
> :old values) of a table in the where clause... Ok if table is small
> but bit of an overkill if table has e.g. > 25 columns.
>
> > Advantage of this is you don't have to worry about someone changing data
 and
> > forgetting to update the timestamp.
> > Jim
> >
>
> With OP's suggestion, you only need a rowid/PK and timestamp to verify
> if the row has been updated by another user. As far as user forgetting
> to update the timestamp... this can be easily controlled by either a
> before insert or update trigger (:new.timestamp := sysdate) or a
> packaged insert procedure with no direct access to the table.
>
> Regards
> /Rauf Sarwar
Received on Mon Jun 09 2003 - 01:37:13 CEST