BananaDB Change Log

======================= Trunk (not yet released) =======================

Changes in runtime behavior


API Changes

  1. Configuration factored out from Hashtable to a new interface.
     (Karl Wettin)


File format

  1. Hashtable and key postings 1024 bytes headers.
     (Karl Wettin)

     The headers contains data start offset (and more) that is read at every
     access and thus made the way for rehashing on one JVM to "notify" other
     JVMs to start accessing rehashed data.


  2. Key postings header now contains a version.
     (Karl Wettin)

     This long value is increased for each modification to the database.


  3. Hashtable posting points now also points at last key posting offset.
     (Karl Wettin)

     This allows for speedier rehash as it can skip to the last key posting
     rather than iterating all key postings associated with a hash posting.


Bug fixes

  1. Write lock on remove.
     (Karl Wettin)


New features

  1. Rehashing, growing hashtable capacity.
     (Karl Wettin)

     Hashtable and Key postings file now both got a header of 1024 bytes
     that contains start and end offset. On rehash a write lock is set
     and the hashtable and key postings files are appended with null data
     on which the rehashed postings are written.

     When rehash finish, the start- and end offset in the file headers are updated
     and thus any JVM running using the DB will start reading from the rehashed data.

     In the future one should implement
     1. A cleanup() method that removes old posting parts of the files.
     2. Automatic rehasing when the next available offset hits a threadshold. (DONE! see #2)

     CAVEAT!
     Cursors iterating values will throw an exception in case there has been a rehash.


  2. Transactions.
     (Karl Wettin)

     A transaction is always flushed. Supports size(), get(), put(), remove() and containsKey().

     Three sorts of isolation level:
     1. Updated (default), will revert to any changes made to the hashtable since txn was created.
     2. Deadlocking, will throw an exception if changes was made to the same entity since txn was created.
     3. Last commit wins, will override any changes made to the entities in the hashtable since txn was created.


  3. Automatic growing capacity of the hashtable.
     (Karl Wettin)

     Increased the capacity with factor 1.7 when the the key posting space use at least 20%
     of the available space in the key postings file.
     

Optimizations

  1. Read methods of key postings compares using keyhash before unmarshalling key.
     (Karl Wettin)

     A fairly obvious way to save clock ticks when iterating though large key posting lists
     that are associated with the same hash posting.


  2. Speedier rehash by skipping to the last key posting in the chain.
     (Karl Wettin)

Documentation


Build


Test cases




======================= Version 0.1, 2009-03-14 =======================

First post-snapshot version.

Contains a thread safe, non transactional, file system persistent Hashtable<K, V>.
(Karl Wettin)

Uses the Lucene LockFactory mechanism.