![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
MARK CALLAGHAN
As a further optimization, I want a callback that is called after the binlog entries are written for a transaction and before the wait for group commit on the fsync is done. That callback will be used to release row locks (optionally) held by the transaction.
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? For issue 2: Transaction A inserts a row and releases locks early before making the row visible to other transactions. Transaction B inserts the same row. Will we get a duplicate key in the database (corruption) due to uniqueness check in transaction B not seeing the row from A? Or will we get a bogus uniqueness violation in transaction B if A rolls back? Have you already found an answer for issues such as these? One way to avoid these kind of issues seems to me to be A. Do not release row locks until changes made by the transaction have been made visible. B. Do not make changes visible until we are fully decided to commit the transaction. So basically, what I am asking is if you are doing A+B, or if you found a way to release row locks even earlier. Or put another way, exactly how early are you able to release row locks? --- What I currently have is two callbacks for the engine: - One that is called after engine prepare() fsync, and before binlog write/fsync. - One that is called after binlog write/fsync, and before engine commit() fsync. These callbacks are guaranteed to be called in the same order that transactions are written to the binlog. So we can probably release row locks in the second callback. The question is if we can release earlier, in the first callback? And if not, do I need to add a callback that is called after the binlog is successfully written, but before it is fsync'ed to disk? - Kristian.