Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/trafodion/pull/1586#discussion_r192541780
--- Diff: core/sql/runtimestats/sscpipc.cpp ---
@@ -907,3 +910,53 @@ void
SscpNewIncomingConnectionStream::processSecInvReq()
request->decrRefCount();
}
+void SscpNewIncomingConnectionStream::processLobLockReq()
+{
+ IpcMessageObjVersion msgVer = getNextObjVersion();
+
+ ex_assert(msgVer <= currRtsStatsReqVersionNumber, "Up-rev message
received.");
+ NAHeap *statsHeap = NULL;
+ LobLockRequest *request = new(getHeap())
+ LobLockRequest(getHeap());
+
+ *this >> *request;
+ ex_assert( !moreObjects(), "unknown object follows LobLockRequest.");
+ SscpGlobals *sscpGlobals = getSscpGlobals();
+ StatsGlobals *statsGlobals = sscpGlobals->getStatsGlobals();
+ int error = statsGlobals->getStatsSemaphore(sscpGlobals->getSemId(),
+ sscpGlobals->myPin());
+ statsHeap = statsGlobals->getStatsHeap();
+ char *ll = new (statsHeap) char [LOB_LOCK_ID_SIZE];
+ memcpy(ll,request->getLobLockId(),LOB_LOCK_ID_SIZE+1);
+ SyncHashQueue *lobLockList = statsGlobals->getLobLocks();
+ if (ll[0] == '+') // If it's a positive value, we are supposed to insert
it.
--- End diff --
I would suggest the following to avoid this race condition.
1) Obtain a node id based on the lock key. It could be as simple as hash
of the lock key % number of nodes in the cluster
2) Send a message to SSMP to obtain a lock if it is not locked already.
Let SSMP send the lock info to other nodes via SSCP
3) Let SQL process check if it is already locked via the shared segment,
If the lock exists already , poll till the lock is released or pre-determined
timeout expires, When the lock is released send a message to SSMP pertaining to
lock key to lock,
4) If this request returns if it is locked already, continue to poll
locally to check the lock is released as in 3 to take care of two waiters
waking up at the same time to obtain lock.
However this would cause all SQL processes to have opens to all SSMPs in
the cluster.
Also, this concept of locking via RMS can overwhelm the RMS infrastructure.
So, we should have mechanism to disable it if needed.
---
