Date: Fri, 23 May 2003 15:32:28 -0500
From: Bruno Wolff III <bruno@wolff.to>
To: Jeff Pogodzinski <jrpogo@yahoo.com>
Cc: pgsql-sql@postgresql.org
Subject: Re: libpq program SELECT FOR UPDATE and TIMEOUT or CANCEL REQUEST
Message-ID: <20030523203228.GA26249@wolff.to>
Mail-Followup-To: Jeff Pogodzinski <jrpogo@yahoo.com>,
 pgsql-sql@postgresql.org
References: <20030523150816.GA3935@wolff.to>
	<20030523200352.35909.qmail@web11505.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030523200352.35909.qmail@web11505.mail.yahoo.com>
User-Agent: Mutt/1.5.4i

On Fri, May 23, 2003 at 13:03:52 -0700,
  Jeff Pogodzinski <jrpogo@yahoo.com> wrote:
> Hi Bruno, 
> 
> > It is generally bad design to hold database locks while waiting for
> > user input. It is generally better to keep information about updates
> > in a table and have the applications use this information to advise
> > or prevent conncurrent updates to the same data by different people.
> 
> How would I advise of prevent conncurrent updates without locks?

You use tables in your database that are checked by the application.
Typically you would store information about what data is being worked
on and who is working on it. That way you don't block the database waiting
for input from humans. If two people want to work on the same data at the
same time, the application decides how to handle that. You may want to
prevent it (with some way to override) or just issue a warning. You may
also want to issue a warning to the second person to commit their changes
warning them that the data has been changed since they started their work.