I am aware it is a string lock, and this is what I want. LOCK TABLES is not suitable for advisory locking. My question is targetted at the usefulness of the GET_LOCK functionality when you can only lock one 'string' per connection.
Richard ----- Original Message ----- From: "gerald_clark" <[EMAIL PROTECTED]> To: "Richard Clarke" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, June 01, 2004 8:39 PM Subject: Re: GET_LOCK(str,timeout) behaviour > GET_LOCK is just a string lock, and has nothing to do with tables. > Use LOCK TABLES instead. > > Richard Clarke wrote: > > >The manual indicates that a GET_LOCK expires automatically when a new > >GET_LOCK is issued. Can someone explain to me how this behaviour could > >possibly be the most useful? > > > >I wish to use GET_LOCK in my applications to provide advisory locking on > >which tables should be used for certain operations. I therefore, at times > >wish to have locks on more than one table for the purpose of a query. > > > >Can I suggest that the implementation of GET_LOCK be changed such that locks > >last up until they are released or the client is diconnected instead of also > >being released when a new GET_LOCK is issued. > > > >I would think that it be much more useful for a client to be able to hold > >multiple locks rather than each lock being released upon request of a new > >lock. I can't think when it would be useful to have the current behaviour. > >Please correct me if I'm wrong > > > >Richard. > > > > > > > > > > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
