MySQL Forums
Forum List  »  NDB clusters

Re: GET_LOCK in ndb clusters
Posted by: Frazer Clement
Date: October 20, 2021 04:01AM

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.

Options: ReplyQuote


Subject
Views
Written By
Posted
862
October 19, 2021 08:23AM
374
October 19, 2021 01:16PM
385
October 19, 2021 03:06PM
433
October 19, 2021 05:20PM
324
October 19, 2021 07:07PM
365
October 20, 2021 09:40AM
313
October 19, 2021 06:09PM
314
October 20, 2021 06:24AM
370
October 20, 2021 06:45AM
331
October 20, 2021 08:19AM
312
October 20, 2021 08:56AM
Re: GET_LOCK in ndb clusters
337
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.