maria-developers team mailing list archive

[Henrik Ingo <henrik.ingo@xxxxxxxxxxxxx>]

Hi Kristian

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

On Fri, Apr 30, 2010 at 10:32 PM, Kristian Nielsen
<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?

Yes?

It seems to me you could still allow this with the condition that
transaction B cannot commit before A has committed. So in the
implementation, A needs to maintain a list of dependant transactions,
and if A is rolled back, also B will be rolled back.

What is completely unclear to me, and I will not spend time thinking
about this today, is whether this maps cleanly to any of the ANSI SQL
isolation levels, since we are kind of seeing uncommitted data, kind
of not...


henrik

-- 
email: henrik.ingo@xxxxxxxxxxxxx
tel:   +358-40-5697354
www:   www.avoinelama.fi/~hingo
book:  www.openlife.cc