[jboss-jira] [JBoss JIRA] (JGRP-2249) CENTRAL_LOCK2: reconciliation protocol on coord change
[
https://issues.jboss.org/browse/JGRP-2249?page=com.atlassian.jira.plugin....
]
Bela Ban resolved JGRP-2249.
----------------------------
Resolution: Done
Done, design doc is [1].
Next step is to think whether distributed conditions really make sense, unless we have
distributed state, too. See my email below:
I'm implementing a new version of the locking protocol, CENTRAL_LOCK2, and am
currently looking at conditions.
Since you're the author of the Condition part of the LockService...
Do you think distributed conditions make sense?
Usually, a condition is associated with some state, and the await()/signal() methods
check/modify that state.
However, to be truly distributed, that state would have to be present in every member, and
be changed in every member accordingly, too.
Do you assume these state changes (e.g. before a signal()) happen outside of the scope of
the LockService, e.g. via messages/RPCs?
I'm think whether we should pull support for conditions, ie. Lock.newCondition() would
throw an UnsupportedOperationException.
How do you guys handle this in the Infinispan locking service (Pedro)?
WDYT?
[1] https://github.com/belaban/JGroups/blob/master/doc/design/CENTRAL_LOCK2.txt
CENTRAL_LOCK2: reconciliation protocol on coord change
------------------------------------------------------
Key: JGRP-2249
URL: https://issues.jboss.org/browse/JGRP-2249
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.13
Implement a reconciliation protocol when the coord changes: instead of backing up all
lock information to another member, the new coord asks all members for their current lock
information (acquired locks, pending acquire and release requests) and constructs the lock
table accordingly.
This is described in https://issues.jboss.org/browse/JGRP-2234 (later comments).
Comment from 2234:
Clients need to have the following information:
* Locks they acquired
* Pending lock requests; locks which they want to acquire but for which they haven't
yet received a LOCK_GRANTED response
* Pending lock release requests; lock that have been released, but for which no
RELEASE_LOCK_OK response has been received
* Ditto for conditions, but we'll tackle them in a second stage
The reconciliation protocol queues all new requests on the coord and asks all members for
their lock information. Once the coord has received this information from all members, it
applies this and then drains the queue of pending requests.
It is important that the requests are ordered per member, ie. a release(L) cannot come
before a lock(L).
Since {{CENTRAL_LOCK}} allows for multiple members to hold the same lock in a split brain
scenario, we need to think about how to handle merging where the coord detects that
multiple members hold the same lock...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)