We are developed a storage engine using row based replication. This
engine is non-transactional and will use row level locking. The row
locks will only be holded for a very short time, just to protect a
single row from concurrent update. If a statement updates multiple
rows, the engine will lock the first row, update it, unlock it, and
lock the second row, update it, unlock it, etc. So the following
senario is possible:
statement 1: update row1;
statement 2: update row2;
statement 1: update row2;
statement 2: update row1;
That is. The final state of row1 is statement 2's, and the final state
of row2 is statement 1's. For proper replication, the binlog events
should be written is the following order:
statement 1's update of row1;
statement 2's update of row2;
statement 1's update of row2;
statement 2's update of row1;
However based on the manual, it seems that multiple binlog events of
the same statement will be cached and be written as a whole unit when
the statement finished.
This will lead to improper replication. So I'm curious to know is this
the case or I misunderstanded.
