Envelope-to: knielsen@knielsen-hq.org
Delivery-date: Thu, 25 Mar 2010 16:14:22 +0100
Date: Thu, 25 Mar 2010 16:14:11 +0100
From: Sergei Golubchik <serg@askmonty.org>
To: Kristian Nielsen <knielsen@knielsen-hq.org>
Cc: Paul McCullagh <paul.mccullagh@primebase.com>,
  maria-developers@lists.launchpad.net
Subject: Re: [Maria-developers] [Bug 544173] [NEW] Server crash for
	multi-engine transaction with binlog disabled
Message-ID: <20100325151411.GA12389@janus.mylan>
References: <20100322134427.7887.94970.malonedeb@palladium.canonical.com> <20100322134427.7887.94970.malonedeb@palladium.canonical.com> <0CA2DF19-EB54-4B3F-9683-E982E3C7E71E@openquery.com> <87aatw97f3.fsf@knielsen-hq.org> <C2FA0C21-CA19-42AD-A268-A05C7908CA2B@primebase.com> <87d3ys7ar5.fsf@knielsen-hq.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87d3ys7ar5.fsf@knielsen-hq.org>
User-Agent: Mutt/1.5.16 (2007-06-09)
Xref: odin maria-developers:2815
Lines: 55

Hi, Kristian!

On Mar 25, Kristian Nielsen wrote:
> Paul McCullagh <paul.mccullagh@primebase.com> writes:
> > On Mar 25, 2010, at 8:39 AM, Kristian Nielsen wrote:
> 
> >> (For example current code has no protection against another
> >> thransaction seeing a transient state with one engine committed and
> >
> > I would be interested in an actual example of something does not
> > work.  Right now I have a problem imagining why something would not
> > work.
> 
> I just happened to run the following test two days ago:
> 
> Consider the following tables
> 
>     create table t1 (a int primary key) engine=innodb
>     create table t2 (b int primary key) engine=pbxt
>     insert into t1 values (1)
>     insert into t2 values (1)
> 
> I run the following statement repeatedly in one thread:
> 
>     UPDATE t1,t2 SET a=a+1,b=b+1
> 
> It would be natural to assume that other threads will never be able to see
> different values for a and b in a single transaction, but that assumption
> would be wrong. I run the following statement repeatedly in a different
> thread:
> 
>     SELECT a,b FROM t1,t2
> 
> After just a few iterations, this will return a row with a=b+1.
> 
> (The reason I did this test was that I was looking at the XA multi-engine
> code, and not seeing any code to enforce cross-engine consistency. I guess
> this test shows there just is no such code ...)
> 
> I didn't report it as a bug, as I was not sure if it is a bug or not ... maybe
> it is? I'd want a better fix than just taking a global lock over every commit
> (which could hurt performance a lot), and such fix may be non-trivial...

It's not. We've discussed that a few times in MySQL a couple of years
ago. XA standard does not mention consistency at all - the consistency
between different participants can only be guaranteed on the
SERIALIZABLE isolation level. As our XA implementation does not put
additional requirements on the engine beyond the XA standard
requirements, it also can only guarantee consistency on the SERIALIZABLE
isolation level.

Regards,
Sergei