Understanding TDB behavior

[Amitay Isaacs]

On Fri, Jul 17, 2015 at 1:56 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> 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.
>
>
I understand if the first process does not have the database open, then the
second opener will the "first" and will wipe the database.  However, in
this case, the first process is still holding the database open without
mutexes.  The second process is not the "first" to open, but the database
gets converted to use mutexes.

Amitay.