MySQL Forums
Forum List  »  NDB clusters

Re: GET_LOCK in ndb clusters
Posted by: Pete Ditmars
Date: October 19, 2021 03:06PM

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?



Options: ReplyQuote

Written By
October 19, 2021 08:23AM
October 19, 2021 01:16PM
Re: GET_LOCK in ndb clusters
October 19, 2021 03:06PM
October 19, 2021 05:20PM
October 19, 2021 07:07PM
October 20, 2021 09:40AM
October 19, 2021 06:09PM
October 20, 2021 06:24AM
October 20, 2021 06:45AM
October 20, 2021 08:19AM
October 20, 2021 08:56AM
October 20, 2021 04:01AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.