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@knielsen-hq.org> 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@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc