List:General Discussion« Previous MessageNext Message »
From:Paul DuBois Date:July 29 1999 11:43am
Subject:Re: On GET_LOCK ()
View as plain text  
At 6:22 AM -0500 7/29/99, <sinisa@stripped> wrote:
>Scott Hess writes:
> > <sinisa@stripped> wrote:
> > > Benjamin Pflugmann writes:
> > >  > > What do you think that I suggest to Monty that we add a
> NON_WAIT
> > >  > > option to the get_lock, which would not hang, but would return
> 0
>if a
> > >  > > lock is struck. In that case, a programmer could check the
> return
> > code
> > >  > > and inform the user that a resource is unavailable .....
> > >  >
> > >  > Either I totally misunderstand you or you are talking about
> > >  > GET_LOCK('foo',0), which is already available and will return 0 in
> > >  > case of an existing lock...?
> > >
> > > Yes, you are partially right.
> > >
> > > '0' is returned when lock has passed it's timeout, which in case of
> > > '0' means always.
> > >
> > > No, there should be then some other value, like '2' or '-1' for non
> > > wait locks
> >
> > Still not sure I'm getting your point, here.  I'm with Benjamin on
>this, the
> > only usage I think get_lock('foo',0) wouldn't allow for is if you didn't
> > want to _aquire_ the lock, but you did want to check if the lock was locked
> > or not.  Even there, you should be able to do something like:
> >
> > SELECT GET_LOCK('foo',0), RELEASE_LOCK('foo');
> >
> > If 'foo' is locked, you'll get 0 and 0 as your result.  If 'foo' is not
> > locked, you'll get 1 and 1 as your result.
> >
> > [In any case, rather than add a NON_WAIT option to GET_LOCK(), it would
> > probably be saner to just add a CHECK_LOCK() function.  GET_LOCK('foo',0)
> > already handles the case where you want to get the lock, but not wait
>to get
> > it.  Adding a NON_WAIT option would leave it ambiguous as to whether you'll
> > get the lock from GET_LOCK().  Another alternative for this idiom would be
> > GET_LOCK('foo', -1), which AFAICT is currently handled just like
> > GET_LOCK('foo',0).]
> >
> > Later,
> > scott
> >
> >
> >
> >
>
>Yes you are right.
>
>The best way to check for lock is with 0 timeout.
>
>Then check for '1' or '0'.
>
>But there still remains to be solved a problem with CGI
>applications. Someone could get a lock, and then wonder off.
>
>The lock will remain !!


On the PHP list, questions come up periodically about "how do I lock
such-and-such" in the context of a Web application.  The answer tends
to be "if you're locking something from the Web, your design needs to
be rethought.

The situation above seems to provide another instance of why
you don't want your Web servers locking things.

--
Paul DuBois, paul@stripped
Thread
Restrict Accesstoxalot27 Jul
  • Restrict Accesssinisa27 Jul
    • Re: Restrict AccessThimble Smith27 Jul
      • Re: Restrict AccessPaul DuBois27 Jul
        • Re: Restrict AccessMartin Ramsch27 Jul
          • Re: Restrict AccessPaul DuBois28 Jul
            • Re: Restrict AccessThimble Smith28 Jul
        • Re: Restrict Accesssinisa28 Jul
    • Re: Restrict Accesstoxalot28 Jul
      • On GET_LOCK ()sinisa28 Jul
        • Re: On GET_LOCK ()Benjamin Pflugmann28 Jul
          • Re: On GET_LOCK ()sinisa28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
          • Re: On GET_LOCK ()Jim Faucette28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
              • Re: On GET_LOCK ()Thimble Smith28 Jul
          • Re: On GET_LOCK ()Gerald Clark28 Jul
        • Re: On GET_LOCK ()Paul DuBois28 Jul
          • Re: On GET_LOCK ()sinisa28 Jul
            • Re: On GET_LOCK ()Paul DuBois28 Jul
  • Re: On GET_LOCK ()Scott Hess28 Jul
    • getting rid of duplicatesJoel Bremson28 Jul
    • Re: getting rid of duplicatesChristian Mack28 Jul
    • Re: On GET_LOCK ()sinisa29 Jul
      • Re: On GET_LOCK ()Paul DuBois29 Jul
    • Re: On GET_LOCK ()Scott Hess29 Jul
Re: On GET_LOCK ()toxalot28 Jul
  • Re: On GET_LOCK ()sinisa28 Jul
    • Re: On GET_LOCK ()Benjamin Pflugmann29 Jul
  • Re: On GET_LOCK ()Sasha Pachev29 Jul
    • Re: On GET_LOCK ()Benjamin Pflugmann31 Jul
Re: On GET_LOCK ()Thimble Smith29 Jul
  • Re: On GET_LOCK ()Fraser MacKenzie29 Jul
    • Re: On GET_LOCK ()Thimble Smith29 Jul
      • Re: On GET_LOCK ()Fraser MacKenzie29 Jul
Re: On GET_LOCK()R. Mentink31 Jul