IBMStreams / streamsx.dps

The IBMStreams/streamsx.dps GitHub repository is home to the Streams toolkit named DPS (Distributed Process Store)
http://ibmstreams.github.io/streamsx.dps
Other
4 stars 9 forks source link

Question: Any more information on the distributed locking scheme? #28

Closed ddebrunner closed 4 years ago

ddebrunner commented 8 years ago

Just wondering if there's any more details on the distributed locking, a namespace-info.spl in the com.ibm.streamsx.lock.distributed covering it in more detail would be a great addition to the toolkit.

nysenthil commented 8 years ago

Hi Dan, At present, there is some detail about the DPS distributed locking feature available in the Streams Knowledge Center. Additional details can be found in the "Distributed Lock functions" section of the original DPS position article we published via IBM developerWorks: http://tinyurl.com/zeej2ny

ddebrunner commented 8 years ago

Is it possible for dlReleaseLock to return if the process still held the lock?

The issue with the current scheme is that once you have acquired the lock you are not guaranteed you still hold it. With a timeout there's no guarantee that the update/read of the store will occur before the lock gets released by the timeout.

nysenthil commented 8 years ago

Hi Dan, Yes. Please see below.

// We have an utility function that will return us the process id currently owning this lock. // Let us exercise that API. mutable uint32 pid = dlGetPidForLock("Super_Duper_Lock", err); if (err != 0ul) { printStringLn("Error in dlGetPidForLock(Super_Duper_Lock) rc = " + (rstring)dlGetLastDistributedLockErrorCode() + ", msg=" + dlGetLastDistributedLockErrorString()); } else { printStringLn("Before lock acquisition: pid owning the Super_Duper_Lock = " + (rstring)pid); }

ddebrunner commented 8 years ago

@nysenthil Not sure how that helps, process identifiers are not unique within a cluster.

What's really needed is validation that the lock previously obtained (in the same thread) is still held at release time.