Re: unlock Select for update - Mailing list pgsql-general

From jose antonio leo
Subject Re: unlock Select for update
Date
Msg-id KAEFLIDKHEJNPPKOLGHMCEIECPAA.jaleo8@storelandia.com
Whole thread Raw
In response to Re: unlock Select for update  (Martijn van Oosterhout <kleptog@svana.org>)
Responses unlock rows  ("jose antonio leo" <jaleo8@storelandia.com>)
List pgsql-general
I know that not a good idea block rows in web environment. But it is a
inheritance. :-(
How can I put in a timeout? Maybe a pgsql parameter?

-----Mensaje original-----
De: Martijn van Oosterhout [mailto:kleptog@svana.org]
Enviado el: martes, 11 de marzo de 2003 11:48
Para: jose antonio leo
CC: pgsql-general; Neil Conway; Bruce Momjian
Asunto: Re: [GENERAL] unlock Select for update


On Tue, Mar 11, 2003 at 11:35:57AM +0100, jose antonio leo wrote:
> Yes...
> It is a web system. I Send part of code and explain in it.
>

[snip code]

>
> In this system if the web user close your browser the row keeps blocked.
>
> I hope that you understand to me

I see what your problem is. When we're talking about closing the connection,
we mean closing the connection *to the database*. Unfortunatly what you are
trying to do is not a particularly good idea.

You see, if the user closes their browser, your program will *not* get told.
As you've noticed, it will wait forever. Since your program never notices
the user has gone away, the record is never unlocked.

There are two (or maybe more) solutions:

1. Put in a timeout so if the user doesn't respond after a period, close the
connection.

2. Don't use the database to do the locking. It's rather risky in an
environment where you can't tell if the user is still alive or if they've
gone for lunch or something.

Perhaps you need to reconsider what you want to happen in these cases.

Hope this helps,

> -----Mensaje original-----
> De: Martijn van Oosterhout [mailto:kleptog@svana.org]
> Enviado el: martes, 11 de marzo de 2003 10:01
> Para: jose antonio leo
> CC: Neil Conway; pgsql-general; Bruce Momjian
> Asunto: Re: [GENERAL] unlock Select for update
>
>
> On Tue, Mar 11, 2003 at 09:10:21AM +0100, jose antonio leo wrote:
> > Unfortunately In my aplication this non occur . When the client
> disconnects
> > the row keep blocked and then I have kill the process manually for
> unlocked
> > the row.
> >
> > You know why it happends?
>
> You're obviously doing something wrong, since if the client disconnected,
> then there would be nothing to kill. You'll need to explain more about
your
> system before we can help you.
>
> > -----Mensaje original-----
> > De: Neil Conway [mailto:neilc@samurai.com]
> > Enviado el: lunes, 10 de marzo de 2003 19:05
> > Para: jose antonio leo
> > CC: Bruce Momjian; pgsql-general
> > Asunto: RE: [GENERAL] unlock Select for update
> >
> >
> > On Mon, 2003-03-10 at 12:15, jose antonio leo wrote:
> > > Sorry, I explain more...
> > > I have got a aplication that it do maintenance of DB, One user are
> > updating
> > > a row locked for a select for update and this user switch off your pc
> and
> > he
> > > leaves the row locked.
> >
> > When the client disconnects, any uncommitted transaction (if any) will
> > be aborted, so the lock will be released.
> >
> > Cheers,
> >
> > Neil
> >
> > --
> > Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> >
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
> --
> Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> > Support bacteria! They're the only culture some people have.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Support bacteria! They're the only culture some people have.


pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: unlock Select for update
Next
From: Martin Paulďuro
Date:
Subject: Create Stored procedure