IMHO the project made a critical design error by trying to be backend agnostic. From a technical perspective, that gives the worst of all worlds for everyone involved.
IMHO the project made a critical design error by trying to be backend agnostic. From a technical perspective, that gives the worst of all worlds for everyone involved.
Why do you need both a BerkeleyDB and PersistIt backend? At the absolute most you should have 2 or 3. Single Machine, AP Cluster, ACID Cluster.
7 backends means 7 different database products, with the same API facade. Duh right? Well the problem is that constrains your API to a least common denominator feature set, limiting access to the unique attributes and capabilites of the underlying backend. Not to mention completely abstracting away memory/disk issues. This is a really big issue with your approach. You have some sunken costs here but I think eventually you will see the value in tightening up your focus.