RE: Lock rekord

From: Pawe Dubin <paweld(at)suimed(dot)tpnet(dot)pl>
To: pgsql-general(at)postgresql(dot)org
Subject: RE: Lock rekord
Date: 2000-06-19 06:57:50
Message-ID: 00061909151000.00637@paweld
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrea Aime 2000-06-19 07:06:21 PostgreSQL on NT: new cygwin?
Previous Message T.J.Farrell 2000-06-19 04:18:10 Re: Read an already existing DB: functions & triggers.