From: | "Andrew Snow" <als(at)fl(dot)net(dot)au> |
---|---|
To: | "Pgsql-General(at)Postgresql(dot) Org" <pgsql-general(at)postgresql(dot)org> |
Subject: | RE: Lock rekord |
Date: | 2000-06-17 17:35:15 |
Message-ID: | NHEALMDKDACEIPBNOOOCOEMICFAA.als@fl.net.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> 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.
What happens if someone else updates the record *just* after the record is
reread for update and timestamp compared?
- Andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Vipin Samtani | 2000-06-17 19:37:26 | ALTER TABLE to add Foreign Key Constraint |
Previous Message | Herbert Liechti | 2000-06-17 17:16:04 | Re: Lock rekord |