Re: GET_LOCK in ndb clusters

[Pete Ditmars]

Hi Jon,

I think I'm replying to the correct reply this time :-).

I looked at the updates in this section, which I'll try to quote here:

-----

21.2.7.10 Limitations Relating to Multiple NDB Cluster Nodes


- No distributed table locks.

A LOCK TABLES statement or GET_LOCK() call works only for the SQL node on which the lock is issued; no other SQL node in the cluster “sees” this lock. This is true for a lock issued by any statement that locks tables as part of its operations. (See next item for an example.)

Implementing table locks in NDBCLUSTER can be done in an API application, and ensuring that all applications start by setting LockMode to LM_Read or LM_Exclusive. For more information about how to do this, see the description of NdbOperation::getLockHandle() in the NDB Cluster API Guide.

-----


I'm not sure GET_LOCK should be lumped in with table locks. I believe it's providing what's known as "user-level locks".

I'm also not sure any of the rest of those 2 paragraphs apply to user-level locks, like I'm thinking that NdbOperation::getLockHandle() is not going to help enable cluster-wide user-level locks.

I think a new section/bullet with

- No user-level locks.

as the header would be clearer and perhaps with some suggestions/guidance such as what Frazer is suggesting - essentially you can roll your own cluster-wide user-level lock-ish things by using rows in a "user-lock" table of your own (without some of the fun features that GET_LOCK provides).

I still would like to see GET_NDB_LOCK someday.

Thanks,

Pete