Hi Yuan,
No, you are understanding it correctly, each statement is a transactional unit
and all rows are cached until the statement completes.
You might be able to use the "self-logging" flag to indicate that the storage
engine is going to handle the logging itself.
Best wishes,
Mats Kindahl
Yuan Wang wrote:
> 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.
>
--
Mats Kindahl
Senior Software Engineer
Database Technology Group
Sun Microsystems
