Hi guys, so we have clear case where the JDBM backend get corrupted, up to a point a full reimport of the data is required. Lucas also proved that a test will fail, after haing injected 1000 entries and doing 100 rename (https://issues.apache.org/jira/browse/DIRSERVER-1974).
This is more than annoying... I have tested DIRSERVER-1974 with Mavibot, and I can't reproduce the problem, which means the server is safe. The resulting database is 14 Mb big with the 1000 entries being added, which is big, but acceptable. At this point, I wonder if it would not be a safe approach to switch to Mavibot right now ? The pros : - we know that we can't have a database corruption, because each update is a new revision - technically, mavibot is faster than JDBM - we aren't maintaining JDBM, while Mavibot is under development The cons : - Mavibot is still under developement : we still have to add teh cross-btree transactions, which means that if we have a brutal crash during an update, then we may have some inconsistancy in the base (inconsitancy != corruption, but still) - We will still need the global write locking strategy to protect the backend from concurrent reads and write when a update is processed - The database is growing fast due to the limited cleanup we currently do However, in the middle term, Mavibot will bring the following bonuses : - cross btree transaction support (actually, we may even support multiple updates within a single transaction, speeding up the update even more), which will allow us to remove the global RW lock we currently have - bulkloading capacity, increasing teh speed of injecting data by at leats 2 orders of magnitude (server being stopped) So, I'll ask you : what about releasing M21 with Mavibot as a default, but with a possibility for users to still pick JDBM on demand ?
