<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 15 Mar 2012, at 18:10, Dan Berindei wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi Pedro<br><br>On Thu, Mar 15, 2012 at 4:42 PM, Pedro Ruivo <<a href="mailto:pruivo@gsd.inesc-id.pt">pruivo@gsd.inesc-id.pt</a>> wrote:<br><blockquote type="cite">On 3/15/12 1:36 PM, Dan Berindei wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On Thu, Mar 15, 2012 at 10:31 AM, Bela Ban<<a href="mailto:bban@redhat.com">bban@redhat.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 3/12/12 3:03 PM, Dan Berindei wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Sat, Mar 10, 2012 at 7:07 PM, Bela Ban<<a href="mailto:bban@redhat.com">bban@redhat.com</a>> wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">If my last statement is correct, is it safe to assume that with DIST and<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">transactional modifications, I will have a lot of TX contention /<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">collisions ?<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Not sure what you mean by lot of TX contention - lock contention<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">should only depend on the dataset size, unless we use lock striping,<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in which case it depends on the configured concurrency level.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I meant TX rollbacks due to overlapping locks at different nodes, the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">stuff Pedro wrote about in his paper on total order.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Hmm, I thought because we sort the keys before locking it shouldn't be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">possible to have deadlocks between prepare commands. I was assuming<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that the Tx aborts in Pedro's tests were due to write skew check<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">failures, but I just read his message again and he mentions write skew<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">check is disabled.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I must be missing something...<br></blockquote></blockquote><blockquote type="cite">I think that a transaction aborts if a scenario like this occurs:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">4 nodes, N1 to N4.<br></blockquote><blockquote type="cite">N2 is the primary owner of KeyA.<br></blockquote><blockquote type="cite">N3 is the primary owner of KeyB.<br></blockquote><blockquote type="cite">N1 is executing the transaction Tx1 which writes in A and B<br></blockquote><blockquote type="cite">N4 is executing the transaction Tx2 which writes in A and B.<br></blockquote><blockquote type="cite">Both transactions try to prepare at the same time. This scenario can<br></blockquote><blockquote type="cite">occurs (I think):<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">N2 -> deliver(Tx1), lock(KeyA), deliver(Tx2), tryLock(KeyA) //Tx2 is<br></blockquote><blockquote type="cite">blocked until the lock of KeyA is released<br></blockquote><blockquote type="cite">N3 -> deliver(Tx2), lock(KeyB), deliver(Tx1), tryLock(KeyB) //Tx1 is<br></blockquote><blockquote type="cite">blocked until the lock of KeyB is released<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Eventually Tx1 or Tx2 (or both) will be aborted by a timeout. Is this<br></blockquote><blockquote type="cite">behavior correct? Am I missing something?<br></blockquote><blockquote type="cite"><br></blockquote><br>Thanks for the example Pedro, a deadlock can indeed appear in this scenario.<br><br>I kept thinking that because we sort the keys, the Tx2 prepare won't<br>start locking KeyB until it has successfully acquired KeyA.<br>But that's not true, because the Tx2 prepare on N3 doesn't even try to<br>acquire KeyA (as N3 is not the primary owner). So it can go ahead and<br>lock KeyB instead, leading to the deadlock you described.<br></div></blockquote></div>We have a solution for this problem, it's not implemented yet: <a href="https://community.jboss.org/wiki/IncrementalOptimisticLocking">https://community.jboss.org/wiki/IncrementalOptimisticLocking</a></body></html>