In case of pessimistic locking the lock is freed if the lock-owner is expelled from the cluster.
The cluster is able to get a lock for the entry even if the original lock-owner is still alive (but not longer a member of the cluster)
In this case there is a possibility for an inconsistency after the cluster is merged.

The two scenarios are
1) one or more nodes are disconnected to the others by network issues
2) one node is blocked by a full GC ( or suspended for another reason)

The first case must be handled by enable partition handling and set a merge policy to solve the conflict.
The second one is not handled by partition handling and here it is possible that the remaining cluster will get the lock and changed the entry until the original owner is merged back, and due to the 'stop the world' pause continue and change the entry based on the old state without failure - and this will cause unexpected inconsistent results.