directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject JDBM transaction manager
Date Thu, 17 Jan 2013 09:39:48 GMT
Hi guys,

atm, we aren't using the JDBM transaction manager (well, it's a bit of a
mess : the MasterTabe explicitely disable the usage of a TM, so is the
JdbmRdnIndex, but the normal indexes are using the default TM). This
leads to some inconsistencies when the server is brutally stopped, as
the *.db files may not be consistent.

I have tried to disable the TM for indexes, and it seems to work on my
mac, but on windows, this is another story...

I will investigate what's going on on windows, because there is no
reason for such a strange behavior - the very same for linux -.

OTOH, I do think that using a TM is a good idea : as a journal will be
used on startup to update the database if the server crashed, and as
this guarantees that the database will be consistent after a restart,
there is no reason to disable the TM, except that it slows down the
update operation by a factor of two (It's not that problematic).

Still, it's not that simple : as any modification implies the update of
many btrees, we may have some btrees which will be in a good state, and
some other in a previous state, if we have a crash in the middle of a
commit. The update operation is a bit complex, and can be seen as a 2
phases operation :
1) update the Master table, the RdnIndex (many times) and all the indexes
2) commit all the tables (and some of them have 2 btrees)

If we have a crash in phase 1, we are safe. As we hav'nt commit anything
yet, we will recove the database as it was before the crash (to be
double checked)

If we have a crash during the second phase, it's way more problematic :
some indexes may point to the master table, but we may lack some index
if they haven't been committed. The commit order is critical here : we
must update the master table first, then the RdnIndex table, then all
the indexes.

In case we have had a crash, we should be able to detect such a
situation, in order to restore the missing indexes. as soon as the
master table is committed, we are pretty safe and we can restore
everything (but the RDN index). It's easy to check that all the indexed
attributes have been updated - or not - and update them if needed. This
can be done on startup.

All what we need is a file containing the last updated entry (and we
just need to store the enty's DN and its UUID). This file should be
updated when we are done with phase 1, and cleaned when we are done with
phase 2. If the file is empty at startup, we can safely assume the
databse is not corrupted. Otherwise, we just have to check that the
master table, the RdnIndex and all the other indexes have correctly been
updated, and if not, inject the missing elements.

I will work on such a scenario today.

Emmanuel L├ęcharny 

View raw message