$MODULE = "MLDBM::Sync"; $VERSION = .09; $DATE = 'TBA';

+ Deletion of lock file when calling CLEAR(), or %dbm = ()
  Do this after unlock, which _might_ have a race condition
  but haven't seen in in heavy load testing... MLDBM::Sync
  recreates the lock file every time if necessary, so this
  may not be an issue anyway.

- Bug fix for undefined warning in MLDBM::Sync::SDBM_File

$MODULE = "MLDBM::Sync"; $VERSION = .07; $DATE = '2001/03/18';

+ $dbm->SyncCacheSize() API activates 2nd layer RAM cache
  via Tie::Cache with MaxBytes set.

+ CACHE documentation, cache.t test, sample benchmarks
  with ./bench/bench_sync.pl -c

$MODULE = "MLDBM::Sync"; $VERSION = .05; $DATE = '2001/03/13';

+ Simpler use of locking.

- Read locking works on Solaris, had to open lock file in 
  read/write mode.  Linux/NT didn't care.

$MODULE = "MLDBM::Sync"; $VERSION = .03; $DATE = 'TBA';

+ $dbm_obj->SyncKeysChecksum(1) API documented.
  New internal format that does not store the original key
  with keys() & each() throwing errors now if used on this
  kind of database.

+ ReadLock() API added, that does a LOCK_SH internally.
  Also uses ReadLock() for FETCH and *KEY operations.
  ** WARNING: one may not ReadLock() and then write to the 
  dbm, or that will die in an error.  Must UnLock() first.
  Writes may only occur in a Lock() section, which does a 
  LOCK_EX internally.

+ Better backward compatibility with old SDBM_Files
  for MLDBM::Sync::SDBM_File, also new format not compatible
  with .01 format.

+ Better test for MLDBM::Sync::SDBM_File, using keys with
  odd characters.

$MODULE = "MLDBM::Sync"; $VERSION = .01; $DATE = '2001/02/07';

+ Initial release with flock concurrent access control to 
  MLDBM databases.  

+ Also MLDBM::Sync::SDBM_File wrapper for getting around the 
  1024 byte / record limitation for sDBM_File.  Writes data
  in segments of 128 bytes.  This was created because SDBM_File
  access is an order of magnitude faster than DB_File on Linux
  with tie/untie per write in the MLDBM::Sync model, which is 
  for i/o flushing do dbms don't get corrupt.  

  But, then one has to worry about exceeding the 1024 byte limit, 
  which can happen for serializing larger objects.  Well worry
  no more!