Re: GET_LOCK in ndb clusters

[Pete Ditmars]

Thanks Frazer for the reply.

We did (also) implement some simple "user-defined" lock/lease concepts in a regular table that has as a primary key the id of the "named lock", and it's good to hear that the insert/update/delete will serialize properly. (We just also liked some of the features of GET_LOCK in some other areas... the user-defined lock/lease concept is not as powerful.)

I just want to be doubly sure about what the below guidance from Mikael means

----
locks in NDB is currently best performed on application level using a row
per table to be lockable and ensuring that all applications start
by either performing LOCK IN READ MODE to get a shared lock or
LOCK IN EXCLUSIVE MODE to get an exclusive lock on the table.
----

So, if I have a table like this:

----
mysql> describe object_lock;
+------------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+-------+
| id | varchar(500) | NO | PRI | NULL | |
| requestId | varchar(255) | YES | | NULL | |
| startTime | datetime | YES | | NULL | |
| updateTime | datetime | YES | | NULL | |
| idleSecondsLimit | int | YES | | NULL | |
----

and just do normal
"INSERT INTO object_lock ..."
"UPDATE object_lock ... where id = ..."
"DELETE FROM object_lock .. where id = ..."

Then the ndb storage engine will take exclusive locks on the affected rows and the behaviors will be as expected even with clients operating simultaneously across the ndb cluster attached to multiple mysqld processes.

I just want to be sure about where the LOCK IN READ MODE and LOCK IN EXCLUSIVE MODE Mikael mentioned factors in... because we're presently not specifying these.

Thanks Frazer and Mikael,

Pete

p.s. - I just cannot seem to reply to the correct reply... forgive the incorrect reply-nesting. :-)



Edited 1 time(s). Last edit at 10/20/2021 06:47AM by Pete Ditmars.