On 18 May 2011, at 13:33, Mircea Markus wrote:
On 18 May 2011, at 12:44, Manik Surtani wrote:
> Some thoughts:
>
> 1. Suggesting deferring local locks till prepare-time: wouldn't this create a
potentially large number of transaction failures? Since write skews and overwriting may
become a problem if this is allowed.
Not sure I get you, can you please detail.
Pls see my response to Sanne's comment. :)
> 2. Good point, except that how do you deal with failover, e.g.,
if the primary owner fails before broadcasting locks on other data owners (its peer group
for a given key)?
E.g. in the digram, if N3 fails before triggering 2 then N1 will be notified and can
reissue the put to the new owner.
More interesting what happens if 2 is successful and N3 fails before ack to N1. This
needs some more thought..
Right. Maybe we need some form of re-entrancy so if N1 is unsure that N3 succeeded in
pushing the lock to N4, and N1 retries on N4, this should be allowed through.
> Further, doesn't this approach reduce parallelism in
unicasts? E.g., currently, N1 sends requests to N3 and N4 in parallel. With the proposed
scheme, N1 will send a request to N3, and then N3 sends one to N4, in sequence.
this is documented: the optimisation only makes sense when there's high contingency
on same key.
You mean high contention? Yes.
> 3. Need to think more about this, around implications of
correctness of lock acquisition is reordered. But in terms of algorithm, sorting on
identity hashcode won't work since this will be different on different requestor JVMs.
The algorithm does NOT sort on identity hash code, but on CH. For conflict resolution
(i.e. two keys that have same consistent hash) it can use object's hash code (default)
or allow user to specify a hash code function if needed.
Hmm. How does this work with the grouping API, where keys wrapped in a single transaction
would most likely have the same group ID, which is the basis for the hashcode used in the
consistent hash location. This would render any such ordering algorithm useless...
> 4. The "alternate solution" here does not cover the
case of N3 failing before it propagates the lock to N4, thereby invalidating the prepared
state of both tx1 and tx2.
There's no lock propagation from N3 to N4..
Ok. So what happens to tx1 and tx2 in this case? Do they fail heuristically after
preparing successfully?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org