-
1. Re: when can we have the distributed lock available?
I must say it is not high on our prio list. Vote on it (JBCACHE-1098) and I'll see what we can do about increasing prio.
-
2. Re: when can we have the distributed lock available?
This is something I really would like to see us do soon after MVCC and partitioning.
-
3. Re: when can we have the distributed lock available?
the distributed lock can be done easily with client/server mode like terracotta, the central point server can coordinate the lock, but with pojo cache's buddy concept, I am not sure how this can be implemented, probably, it has to select a master node dynamically and use master node to coordinate the lock.
-
4. Re: when can we have the distributed lock available?
We do have some ideas around cooperative locking for this, which will work quite well even without a central server. And pretty easy to implement now that I refactored the lock manager in 2.2.0. :-)
Will get around to documenting ideas around this on the JIRA. Feel like contributing the code if I put up the detailed designs? :-) -
5. Re: when can we have the distributed lock available?
Right, the problem with the single coordinator approach used in a client/server model is that scalability is limited to that coordinator. Ideally, the use of distributed locking would not limit the size of the cluster/grid. It's also important that the lock state is shared by some portion of the cluster in case that coordinator goes down. Finally, the use of distributed locking should be an option that is only enabled when it is actually needed (for things like counters etc), as the replicate + local lock model will always be more efficient.
The desired semantics are very much aligned with data-partitioning, so should be easy to build off it once it is implemented.