In the last episode (Jun 24), Tim Gustafson said:
> Hrmm, something didn't work quite right. Here's the actual query:
> select x, y, zoom from map_images where image_data_size = 0 and
> get_lock(concat(x, ',', y, ',', zoom), 0) = 1 order by zoom
> , sqrt(pow(x, 2) + pow(y, 2)) limit 1
> I've added the image_data_size column and indexed it, and set its current
> value to length(image_data), and modified my "update" query to set
> image_data_size correctly once the job is done.
> When I run more than one compute job, they all start processing the same
> job simultaneously. What am I missing?
That shouldn't happen, since get_lock() will only succeed for one mysql
connection at a time. If you can easily edit the code that is running these
queries, can you add a "select is_used_lock('x,y,zoom')" query right after
your first query, and another one just before your compute client exits?
(You'll have to build the "x,y,zoom" string from the values returned by the
first query) It'd be nice if there was an information_schema table that
listed all currently-held locks, but there isn't :(
is_used_lock() will return the mysql connection ID of the session holding
the lock, so what I am expecting to see is zeros, meaning that for some
reason your mysql connection is getting dropped after your first query
completed. Locks are held for the lifetime of a connection, so if you
disconnect, your lock disappears.