Re: GET_LOCK in ndb clusters

[Frazer Clement]

Hi Pete,
The cluster will serialise transactions using exclusive locks on the same [set of] primary key [ s ].
INSERT, UPDATE, DELETE all take exclusive locks on affected rows and so will serialise with each other.
SELECT ... FOR UPDATE takes exclusive locks and so will serialise with other SELECTs, or INSERT, UPDATE, DELETE.
You can use these properties to e.g. create a table of named locks, with the name as primary key, and other lock info as data. The existence of a row with a given name implies that the named resource is locked.

Looking at the locking functions description, the things that would be missing would be :
- Arbitrary claim timeout (can implement with retries, to some granularity)
- Recursive locking
- Deadlock detection
- Automatic cleanup on session termination
- Client session id associated data - not so useful across MySQLDs

Considering the cluster context, there should also be consideration given to :
- Handling MySQLD failure - cleanup of locks owned by (clients of the) failed MySQLD
- Handling cluster disconnect - invalidation of claimed locks on disconnected MySQLD

Probably it would make sense to define some stored procedures to encapsulate the ways in which such a service would be used.
Implementing a fully general system is harder than something more specific, so perhaps you can build what you need from what is already available.
Frazer



Edited 1 time(s). Last edit at 10/20/2021 04:02AM by Frazer Clement.