On 29/07/14 20:06, Sanne Grinovero wrote: > This is a nasty problem and I also feel passionately we need to get > rid of it ASAP.
+1 > I did have the same problems many times, and we discussed this also in > Farnborough; AFAIR Dan and Pedro had some excellent ideas to fix this. > > You don't need TO, and you don't need to lock at all as long as you > guarantee the backup owners are getting the number with some > monotonicity sequence attached to it, > all that backup owners need to do is ignore incoming commands which > are outdated. Right. And we need to handle the scenario where we get updates from multiple members, e.g. P40,P41,Q6,Q7 in the case where the primary owner changed from P to Q (or from Q to P ?) > Another aspect is that the "user thread" on the primary owner needs to > wait (at least until we improve further) and only proceed after ACK > from backup nodes, but this is better modelled through a state > machine. (Also discussed in Farnborough). > > It's also conceptually linked to: > - https://issues.jboss.org/browse/ISPN-1599 > As you need to separate the locks of entries from the effective user > facing lock, at least to implement transactions on top of this model. > > I expect this to improve performance in a very significant way, but > it's getting embarrassing that it's still not done; at the next face > to face meeting we should also reserve some time for retrospective > sessions. Yes - there's a link to the agenda of the 2015 team meeting, please feel free to update the agenda. I'll send out an email re dates and location shortly. [1] https://mojo.redhat.com/docs/DOC-977279 -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
