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
