Re: GET_LOCK in ndb clusters

[Pete Ditmars]

Thank you Mikael.

I think this needs some red flags in the documentation, both in the ndb limitations section and in the GET_LOCK section. If someone can point me at the right bug reporting mechanism I'll file a bug for that.

Longer term, it'd be great if GET_LOCK could work ndb cluster wide. I'll file an enhancement request for that too. :-)

GET_LOCK is a way to allow applications to coordinate access to anything that can be named. It was particularly attractive in a clustered environment to keep different applications in sync with one another.

If we wanted to replicate some of GET_LOCK ourselves in an ndb cluster database, by simply using a table that holds "named_lock" rows (each row having some unique identifier for the thing-to-be-locked), would simple "insert" and "update .. where" and "delete .. where" statements issue the correct row locking to ensure that all applications would see the same "truth" - that is, two applications trying to "insert" simultaneously to obtain a lock would result in one succeeding and one failing? Same goes for two "update .. where" statements where two clients were trying to update the same row - one would succeed and one would fail (if we gave it the right kind of "where token = x" where token would be updated from an old to a new value)? Is there any "extra" syntax required other than standard mysql syntax to ensure things would work as expected in ndb cluster?

Thanks,

Pete