Open Stack

On 02/11/2015 07:58 AM, Matthew Booth wrote:
> 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.

Exactly correct.

Best,
-jay