directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject [Mavibot] Transactions & troubles...
Date Thu, 19 Dec 2013 08:57:21 GMT
Hi guys,

I knew that adding transactions will not be as easy as I thought ;-)

Ok, yesterday, after having cleaned up the code base, I started to play
with the txn support. The idea is to differ the disk update until a
commit is done (in case a rollback is called, then nothing will be
written on disk). So far, so good, the mechanism is quite simple (except
that I have to add some hooks in the existing code to update pages in
memory until the txn is committed, plus to deal with access to those
pages instead of reading them from disk, in case we update them more
than once).

The real pb arise when it comes to update the BTree headers. As we want
to support cross-btrees txn, we have to guarantee that if we have a
crash in the middle of this update on disk, then we can recover from a
stable version (ie, at the point where the txn started). This is only
possible if we keep a track of the previous BTree headers, beside the
new btree headers. Alas, we don't have such a thing : we just update the
BTree header on place. That means we may have some updated BTrees, and
some ancient BTrees on disk. This is not flying *at all*.

We have to keep a copy of each BTree header, and update the copy when we
do a commit. When the commit is fully done, then we have to update the
first page to make it point to the copy headers, which will become the
current headers (and make the old curent headers to become the copy
headers).

We need a way to keep a reference to the up-to-date BTree headers (all
of them) which can be validated in one single update on disk (ie,
updating the first page). Atm, I think we can use a Btree for that
purpose, assuming we just need to keep the 2 latest revisions. An
alternative would be to have 2 arrays pointing to the updated Btree
header versions and to the new BTree header versions, that would also
fly (I think) but that would not be very consistent with our current design.

All in all, we are no so far, but we need to rethink this point (well,
*rethink* is probably the wrong verb : that would preclude we have
already spent some time thinking about this problem, which would be a
gross exageration ;-)

This is really an exciting project with a lot of challenging problems ...

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com 


Mime
View raw message