Comments on: How to coordinate distributed work with MySQL’s GET_LOCK http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/ Stay curious! Wed, 09 Jul 2008 04:07:26 +0000 http://wordpress.org/?v=2.2.2 By: Shehan http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-14431 Shehan Mon, 14 Apr 2008 03:16:38 +0000 http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-14431 I'm having a hard time to use "GET_LOCK()" function. Can comeone explain how this work and put some sample code. I'm using InnoDb storage even. But when I apply the function it gives nothing. please help. Thanks! I’m having a hard time to use “GET_LOCK()” function.
Can comeone explain how this work and put some sample code.

I’m using InnoDb storage even. But when I apply the function it gives nothing.

please help.
Thanks!

]]> By: Partha Dutta http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1266 Partha Dutta Fri, 28 Jul 2006 15:52:18 +0000 http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1266 <p>Also, If the session is interactive, you also have to worry about any interactive_timeout or wait_timeout sessions. Otherwiseif the session disconnects, the <code>GET_LOCK</code> will release the lock immediately.</p> Also, If the session is interactive, you also have to worry about any interactive_timeout or wait_timeout sessions. Otherwiseif the session disconnects, the GET_LOCK will release the lock immediately.

]]> By: Xaprb http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1255 Xaprb Thu, 27 Jul 2006 20:09:05 +0000 http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1255 <p>Sure, for work that's done in the database locks are a bad thing. In my case, the applications are working outside the database, and we just use MySQL as a central point of control. Remember GET_LOCK() doesn't actually get a lock on anything, per se.</p> <p>The types of applications we're trying to make mutually exclusive are such things as a script to upload a set of ads to a search engine. Allowing more than one to proceed, and then trying to resolve conflicts later, will most certainly not work :-) The work must be done by one and only one program. Another example is rolling up the tables I referred to a couple articles ago. We don't want that happening twice at once, as it's nothing but double work to produce the same answer.</p> <p>So we actually use these "locks" to just make sure only one thing can run (hence the "highlander" name -- "there can be only one!!!!" -- and no, I've not seen the movie)</p> Sure, for work that’s done in the database locks are a bad thing. In my case, the applications are working outside the database, and we just use MySQL as a central point of control. Remember GET_LOCK() doesn’t actually get a lock on anything, per se.

The types of applications we’re trying to make mutually exclusive are such things as a script to upload a set of ads to a search engine. Allowing more than one to proceed, and then trying to resolve conflicts later, will most certainly not work :-) The work must be done by one and only one program. Another example is rolling up the tables I referred to a couple articles ago. We don’t want that happening twice at once, as it’s nothing but double work to produce the same answer.

So we actually use these “locks” to just make sure only one thing can run (hence the “highlander” name — “there can be only one!!!!” — and no, I’ve not seen the movie)

]]> By: Jay Pipes http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1254 Jay Pipes Thu, 27 Jul 2006 19:53:26 +0000 http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1254 <p>Hi!</p> <p>Locking of any sort, IMHO, causes scalability and concurrency issues, even if it is a non-blocking read. Wouldn't a more scalable solution be to simply not set locks at all and resolve conficts at runtime based on a modified date? This is the standard model of distributed version control.</p> <p>Thoughts?</p> <p>-Jay</p> <p>@Toby: I believe that LOCK TABLE would cause a blocking read in PostgreSQL, no? Just like in MySQL, if you issue a LOCK TABLES ... WRITE or SELECT ... FOR UPDATE, it will be a blocking read AFAIK...</p> Hi!

Locking of any sort, IMHO, causes scalability and concurrency issues, even if it is a non-blocking read. Wouldn’t a more scalable solution be to simply not set locks at all and resolve conficts at runtime based on a modified date? This is the standard model of distributed version control.

Thoughts?

-Jay

@Toby: I believe that LOCK TABLE would cause a blocking read in PostgreSQL, no? Just like in MySQL, if you issue a LOCK TABLES … WRITE or SELECT … FOR UPDATE, it will be a blocking read AFAIK…

]]> By: Toby http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1247 Toby Thu, 27 Jul 2006 16:43:53 +0000 http://www.xaprb.com/blog/2006/07/26/how-to-coordinate-distributed-work-with-mysqls-get_lock/#comment-1247 <p>Yes, this lock is perfect for a project I'm working on too. I use it to protect a critical section - an algorithm that operates on one table. A stored procedure would use the lock in the same way.</p> <p>PostgreSQL could achieve the same effect (for my purposes) using <code>LOCK TABLE</code>.</p> Yes, this lock is perfect for a project I’m working on too. I use it to protect a critical section - an algorithm that operates on one table. A stored procedure would use the lock in the same way.

PostgreSQL could achieve the same effect (for my purposes) using LOCK TABLE.

]]>