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. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
