On 10/02/15 18:29, Jay Pipes wrote: > On 02/10/2015 09:47 AM, Matthew Booth wrote: >> On 09/02/15 18:15, Jay Pipes wrote: >>> On 02/09/2015 01:02 PM, Attila Fazekas wrote: >>>> I do not see why not to use `FOR UPDATE` even with multi-writer or >>>> Is the retry/swap way really solves anything here. >>> <snip> >>>> Am I missed something ? >>> >>> Yes. Galera does not replicate the (internal to InnnoDB) row-level locks >>> that are needed to support SELECT FOR UPDATE statements across multiple >>> cluster nodes. >>> >>> https://groups.google.com/forum/#!msg/codership-team/Au1jVFKQv8o/QYV_Z_t5YAEJ >>> >> >> Is that the right link, Jay? I'm taking your word on the write-intent >> locks not being replicated, but that link seems to say the opposite. > > This link is better: > > http://www.percona.com/blog/2014/09/11/openstack-users-shed-light-on-percona-xtradb-cluster-deadlock-issues/ > > > Specifically the line: > > "The local record lock held by the started transation on pxc1 didn’t > play any part in replication or certification (replication happens at > commit time, there was no commit there yet)."
Thanks, Jay, that's a great article. Based on that, I think I may have misunderstood what you were saying before. I currently understand that the behaviour of select ... for update is correct on Galera, it's just not very efficient. Correct in this case meaning it aborts the transaction due to a correctly detected lock conflict. FWIW, that was pretty much my original understanding, but without the detail. To expand: Galera doesn't replicate write intent locks, but it turns out it doesn't have to for correctness. The reason is that the conflict between a local write intent lock and a remote write, which is replicated, will always be detected during or before local certification. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
