- Transactional data store
- Concurrent data store
This product helped us to develop a performance-critical DB backend module in the healthcare domain.
Environment corruption is a common problem found when a DB environment is used by more than one process on a machine at a time. Another thing is that an entire page will be locked when updating a record. This will cause locking of other records on the same page. This can be improved a bit more.
I used it for two years, about nine years ago.
When multiple processes are holding handles to same environment, then there is a high possibility that the environment handles might get corrupted and the whole connection to various databases need to be recreated on the fly. This will also cause ongoing DB operations to get terminated. One solution to this problem is to design the DB access mechanism in such a way that only one process (we can call it a server process and it can be a COM server) is holding the database environment handle and all other client process should communicate with this server process to read/write DB records.
There was excellent support in the Oracle Berkeley DB forum. Also, we had an opportunity to talk to a Oracle Berkeley DB technical person in their Japan office.
We had a previous solution. Because of its proprietary nature and non-conformance to our performance requirements, we considered this product.
Initial steps were pretty straightforward.
We were an in-house team. Things such as database page size, locking model, etc. need to be carefully chosen and designed. A prototype development model would be highly effective.
Since I am a technical person, I don't know any good details about pricing.
Because I was primarily concentrating on the performance side of this product, one will have to first benchmark their own performance requirements. Next, consider concurrency requirements. Then, evaluate how Berkeley DB can satisfy your performance and concurrency requirements using a prototype model of software development.