FAQ

Q: I am using BabuDB on Windows. Why do I get warnings from time to time, indicating that files on disk could not be deleted?
A: Unlike Unix, Windows holds mandatory locks on all open files, which keep them from being deleted. This also applies to memory-mapped files, which BabuDB uses by default to access persistently stored index data. When BabuDB internally creates a checkpoint, it attempts to delete redundant index files, which may fail as they are still in use. These files will be deleted when another checkpoint is created after the locks have been released. Please be aware that the warnings do not indicate data loss.

Q: There are many different parameters in the {{{BabuDBConfig}}} constructors. What are the right settings?
A: The configuration parameters are documented in the Javadocs. If you are not sure about certain parameters, you can also use {{{org.xtreemfs.babudb.config.ConfigBuilder}}} for an easy-to-use generation of BabuDB configurations. The configuration builder will use default settings for many specific parameters.

Q: Why am I getting {{{OutOfMemoryError}}}s?
A: Your insertion rate of key-value pairs might be too high. This leads to a growth of memory-resident trees between checkpoints. Furthermore, each insertion needs to be enqueued at the disk logger to be persistently recorded where it consumes memory. If your insertion rate is too high, the garbage collector may also fail to catch up with new memory allocations. Solutions: assign more memory to the VM, reduce the insertion rate, reduce the log size threshold for checkpoints.

Q: Is BabuDB thread-safe?
A: BabuDB is only thread-safe if asynchronous request processing with worker threads is enabled, i.e. {{{babudb.worker.numThreads}}} has been assigned some value > 0.

Q: Do I need worker threads?
A: It depends. Setting the number of worker threads to 0 causes all requests to be processed in the context of the application thread that performes the insertion. This generally leads to a better performance, as no enqueueing and dequeueing of requests is required. However, direct access to BabuDB is only allowed if single databases are not accessed concurrently. If your application is multithreaded and different threads access BabuDB in parallel, worker threads need to be used instead.

Q: Why do I experience a bad insert/lookup performance?
A: The performance can be substantially improved by disabling synchronous logging, i.e. by setting {{{babudb.sync}}} to {{{ASYNC}}}. This causes log entries to be written to disk in an asynchronous manner; however, this comes at the cost of reduced consistency guarantees in the event of a crash. If the system is shut down in a forceful manner, changes pertaining to requests that were enqueued but not yet written by the disk logger will be lost. Note that it is possible to limit the amount of lost changes by setting {{{babudb.pseudoSyncWait}}} to some value > 0 to trade off performance against data loss in the event of a crash.

Q: Will I get a better performance if I run BabuDB with worker threads?
A: It depends. If only single-threaded sequential access to a single BabuDB index is needed, the best performance is attained if worker threads are disabled, i.e. {{{babudb.worker.numThreads}}} is set to 0. If many indices need to be accessed in parallel on a multi-core machine, a reasonable number of worker threads may increase the performance.

Q: Why do I get errors when I try to iterate over an index via a prefix lookup while concurrently performing insertions?
A: It is not allowed to concurrently iterate and insert. That's a limitation of the Java {{{TreeMap}}}, which backs the in-memory trees used in BabuDB. If you need to do both in a concurrent fashion, you have to take a snapshot of your index and iterate over the snapshot instead.