Skip site navigation (1) Skip section navigation (2)

Re: Q: Record Updating/Locking in Web Environments

From: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>
To: Matthew Rice <matt(at)starnix(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Q: Record Updating/Locking in Web Environments
Date: 2001-03-31 18:40:32
Message-ID: 3.0.5.32.20010401024032.00e81e80@192.228.128.13 (view raw or flat)
Thread:
Lists: pgsql-general
At 11:01 AM 3/31/01 -0400, Matthew Rice wrote:
>Hi guys,
>
>I'm looking for some advice from someone that has probably done this before.
>I have a server this is connected to by various client programs (CLI and Web
>Interface for now).

>The problem now is how to do record locking when updating information.
>Providing the user with a record(s) is done in one transaction.  There's
>no difference [yet] of whether they're using that data to edit or read.
>Sending the data back for updating is done as a second transaction.

It's rather difficult because:
1) The users can leave the app anytime without you knowing.
2) The users can open up more than one browser window....

You could implement your own application level MVCC however 2) makes it
difficult in some cases.

It can be a pain - in one app a few of my tables had columns with a
"committed flag", and a transaction id. And the selects all had to have
committed=true.

And this was years ago when I was using MySQL ;).

>I could just associate the timestamp of the record with the user's requested
>data so that if they try to update it and it's been changed out from under
>them, they get an appropriate error.

Yeah that could work.

Cheerio,
Link.


In response to

pgsql-general by date

Next:From: Eric G. MillerDate: 2001-03-31 19:52:47
Subject: Re: function to operate on same fields, different records?
Previous:From: Steve ArasDate: 2001-03-31 18:31:51
Subject: where does the -i go?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group