Open Stack

On Thu Feb 05 2015 at 9:02:49 AM Robert Collins <robertc at robertcollins.net>
wrote:

> On 5 February 2015 at 10:24, Joshua Harlow <harlowja at outlook.com> wrote:
> > How interesting,
> >
> > Why are people using galera if it behaves like this? :-/
>
> Because its actually fairly normal. In fact its an instance of point 7
> on https://wiki.openstack.org/wiki/BasicDesignTenets - one of our
> oldest wiki pages :).
>
> In more detail, consider what happens in full isolation when you have
> the A and B example given, but B starts its transaction before A.
>
> B BEGIN
> A BEGIN
> A INSERT foo
> A COMMIT
> B SELECT foo -> NULL
>

Note that this still makes sense from each of A and B's individual view of
the world.

If I understood correctly, the big change with Galera that Matthew is
highlighting is that read-after-write may not be consistent from the pov of
a single thread.

Not have read-after-write is *really* hard to code to (see for example x86
SMP cache coherency, C++ threading semantics, etc which all provide
read-after-write for this reason).  This is particularly true when the
affected operations are hidden behind an ORM - it isn't clear what might
involve a database call and sequencers (or logical clocks, etc) aren't made
explicit in the API.

I strongly suggest just enabling wsrep_casual_reads on all galera sessions,
unless you can guarantee that the high-level task is purely read-only, and
then moving on to something else ;)  If we choose performance over
correctness here then we're just signing up for lots of debugging of hard
to reproduce race conditions, and the fixes are going to look like what
wsrep_casual_reads does anyway.

(Mind you, exposing sequencers at every API interaction would be awesome,
and I look forward to a future framework and toolchain that makes that easy
to do correctly)

 - Gus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150205/73b8ef18/attachment.html>