On the topic of nested skiplist transactions

Bron Gondwana brong at fastmail.fm
Wed Sep 3 00:32:05 EDT 2008

On Tue, 2 Sep 2008 16:29:33 +1000, "Bron Gondwana" <brong at fastmail.fm> said:
> I've been thinking a bit about transactions and skiplists these past few
> days, since sending the patch that refactors the skiplist locking code.

Wow, this was scarily simple to write.  Really the code changes are
so easy!


* add 'struct txn *next_txn' to struct txn
* in newtxn, check if there's a current txn and copy values from it if
  so, including put it into next_txn of the new transaction
* don't assert that current_txn is NULL when starting a new transaction
* in commit and abort, set current_txn to tid->next_txn rather than NULL
* if current_txn is now NOT NULL, then don't unlock.
* also in commit, if current_txn is NOT NULL, then don't write the COMMIT
  record to the DB or fsync.

It really was that simple... and it compiled first time, which has to be
some sort of a sign.  Ho hum.  OK, so it broke my skiplist tuning patch
and I had to re-build it - just because I changed the logic of the
checkpoint checker - but that's what quilt is so nice for :)

It passes the hammer tests and a bunch of imap rename tests, which isn't
a big surprise, because no code actually uses the "another transaction
still exists" codepaths yet :)

  Bron Gondwana
  brong at fastmail.fm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-skiplist-nested-transactions-2.3.12.diff
Type: text/x-diff
Size: 4957 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20080903/aae94883/attachment.bin 

More information about the Cyrus-devel mailing list