maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Henrik" == Henrik Ingo <henrik.ingo@xxxxxxxxxxxxx> writes:

Henrik> Hi Kristian
Henrik> I don't know why I'm reading this on a Sunday morning, but just a
Henrik> comment without thinking much:

Henrik> On Fri, Apr 30, 2010 at 10:32 PM, Kristian Nielsen
Henrik> <knielsen@xxxxxxxxxxxxxxx> wrote:
>> I was thinking about this idea of releasing row locks early. Specifically
>> about two scenarios: 1) releasing row locks early before having fully decided
>> whether to commit or roll back a transaction; 2) releasing row locks early
>> before changes in the transaction are made visible to other transactions.
>> 
>> For issue 1: Transaction A releases row locks at end of
>> innodb_xa_prepare(). Transaction B starts modifying rows touched by
>> transaction A (eg. UPDATE t SET a=a+1). Transaction A then needs to rollback
>> due to eg. failure during binlog write/fsync. Will transaction B now end up
>> with the wrong value for a?

It depends on how InnoDB works when it comes to MVCC.

In no case should InnoDB be allowed to change a row that was changed
by another not committed transaction.  This would effectively stop
InnoDB from being able to rollback the not committed transaction.

You can't roll back something that is changed by anyone else, at
least the way I think InnoDB (and Maria) is implementing MVCC.

However, one should be able to release all read locks early.

One could theoretically be able to remove the write locks too, if
InnoDB is using the version id to check if the row is visible/updated
or not before accepting another transaction to change it.

This is how Falcon detected conflicts.

Regards,
Monty