Understanding TDB behavior

[Volker Lendecke]

On Thu, Jul 16, 2015 at 05:39:17PM +1000, Amitay Isaacs wrote:
> Hi,
> 
> Recently I noticed an unexpected (at least to me) behavior in TDB.
> 
> One process has created a database without mutex support and is still
> running.
> Second process tries to open the same database with mutex support.
> 
> My expectation was that the tdb_open() in the second process should fail.
> But, the second process succeeds and converts the database to use mutexes.
> 
> Is this expected?
> 
> To check this exhaustively, I wrote a new tdb test (attached) that tries
> various create and open flags combinations.  And as a result here are the
> findings:
> 
> 1. Either TDB_ALLOW_NESTING or TDB_DISALLOW_NESTING is always set for
> create and open.
> 
> 2. Create and open with TDB_MUTEX_LOCKING | TDB_CLEAR_IF_FIRST always adds
> TDB_INCOMPATIBLE_HASH.
> 
> 3. Database created with TDB_MUTEX_LOCKING can only be opened without
> TDB_MUTEX_LOCKING provided TDB_NOLOCK is specified, otherwise fails with
> EINVAL.
> 
> 4. Open with TDB_MUTEX_LOCKING | TDB_CLEAR_IF_FIRST always converts the
> existing database to use mutexes and incompatible hash.

So the first process still has the database open? If it does, we have a
generic CLEAR_IF_FIRST but. If the second TDB_MUTEX_LOCKING opener is
actually the only one to open this database at this moment, then this
is expected behaviour. CLEAR_IF_FIRST means to wipe the database if we
are the first *concurrent* opener.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de