List z dnia: Sat, 17 Jun 2000, :
> > I usually prefer the following trick for preventing long locking
> > times. On every
> > table I define a timestamp field which is updated every time the record is
> > written to the database. If a user edits a record (without
> > locking) and commit his changes
> > the timestamp is returned from the client program unchanged. The program
> > reads the record again for update and compares the timestamp from
> > the database
> > and the timestamp from the user program. If the timestamp has changed
> > in the meantime the record was updated from someone else and the
> > transaction will be rejected.
and all the work done by the user (filling long form) gone out
>
> What happens if someone else updates the record *just* after the record is
> reread for update and timestamp compared?
It's ok. I do the same.
1. Update lock field for marked to transaction (everyone else need to know It
is locked)
2. begin transaction
3. fill form
4. write to database
5. end transaction
6. delete lock field contents
So applicaction should check if record is in transaction via select on lock
field
But it would be very nice to check it via system.
for example if SELECT FOR UPDATE on record being in transaction returns error.
Pawel
