Hi, MARK! On Dec 29, MARK CALLAGHAN wrote:
On Mon, Dec 28, 2009 at 9:20 AM, Sergei Golubchik <sergii@pisem.net> wrote:
trn1> start transaction; insert t1 select * from t2; trn1> commit; trn1>> ... xa_prepare() ...
trn2> start transaction; insert t2 values (1); commit; trn2>> xa_prepare(); binlog.write(); xa_commit();
trn1> ... binlog.write(); xa_commit();
and you have incorrect transaction order in binlog.
There are several issues here: * for SBR, tm1 cannot release row locks until it is guaranteed that it writes the binlog ahead of any dependent transactions. This is guaranteed by locking prepare_commit_mutex at the end of innobase_xa_prepare and not unlocking until row locks are released during the call to innobase_commit.
I don't see what prepare_commit_mutex has to do with it. It is guaranteed by row locks released at commit time, no matter whether prepare_commit_mutex exists or not.
* at least for the plugin the order in which InnoDB prepare is done might not match the order in which transactions are written to the binlog. InnoDB locks prepare_commit_mutex in innobase_xa_prepare after doing a prepare (the call to trx_prepare_for_mysql). It is unlocked after the commit record is written to the InnoDB transaction buffer and before that buffer is flushed to disk. What does match today is the order of transactions in the binlog and the commit records in the InnoDB transaction log.
Yes, and this is what prepare_commit_mutex is for. Regards / Mit vielen Grüßen, Sergei -- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@sun.com> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028 <___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin Häring