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