From: | Hal Davison <hal(at)faams(dot)net> |
---|---|
To: | Jan Wieck <janwieck(at)yahoo(dot)com> |
Cc: | Jose Luis LG <jlopezgonz(at)terra(dot)es>, "'PostgreSQL-interfaces'" <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | Re: Checking if a table locked from pl/pgsql |
Date: | 2002-03-27 15:45:51 |
Message-ID: | Pine.LNX.4.10.10203271043540.16102-100000@development.faams.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
On Wed, 27 Mar 2002, Jan Wieck wrote:
> Hal Davison wrote:
> >
> > In an operational sense, if a user is updating a table for some accounting
> > function then decides to go to lunch leaving the table locked.
>
> Exactly what I expected. You have a severe design flaw in
> your application. Database transactions have to be short and
> never held over actions that could infinitely block, such as
> user interaction, period!
>
> You need application level advisory locks. The abuse of
> database locks for that will not get you very far. Your
> application will not scale and suffer from problems like the
> one you already face.
>
> Ever thought about adding a WEB interface to that
> application? If a user editing some account needs to hold a
> DB lock all the time, you'll not implement it with
> Apache/PHP, that's for sure already. And you'll have to make
> alot of painfull pushups to do it with any other WEB server
> technology.
>
>
> Jan
Jan,
I don't have this problem. A request was issued for an possible example as
to WHY someone would need to determine who has a table locked.
I am quite aware of the implications of table as well as row locking in a
production situation.
--Hal.
From | Date | Subject | |
---|---|---|---|
Next Message | Jose Luis LG | 2002-03-27 16:06:02 | Re: Checking if a table locked from pl/pgsql |
Previous Message | Jan Wieck | 2002-03-27 15:36:39 | Re: Checking if a table locked from pl/pgsql |