TDB2 inclusion?

Rusty Russell rusty at
Sun Jun 5 23:45:05 MDT 2011

On Fri, 03 Jun 2011 14:42:39 +0200, "Stefan (metze) Metzmacher" <metze at> wrote:
> Hi Rusty,
> > Now, I'm not committing to TDB2 stability at this stage, but integration
> > would make my life simpler (vs. continually rebasing).  The major
> > missing piece (other than debugging and tuning) is that I need to
> > implement the ability to read and write TDB1 files.
> > 
> >         git:// #tdb2-wip
> It would be really nice if we could get rid of the TDB_ALLOW_NESTING hack
> and implement nested transactions correctly.
> The API could look like this:
> enum TDB_ERROR tdb_transaction_start(struct tdb_context *tdb,
> 				     uint64_t flags, /* we need a way to do a non-blocking start */
> 				     struct tdb_context **trans);
> When we start a transaction this way, the 'tdb_context' of 'tdb' would
> become read-only
> until tdb_transaction_commit()/cancel() is called on the returned
> 'trans' context.

Interesting idea.  tdb2 already handles multiple opens internally, but
you'll get an error if you try to use one context while another is
holding a lock (eg. in a transaction).  So we have the infrastructure,
it's just a bit fascist for your needs, and it could be relaxed.

> Also the users of the 'tdb' context would see the state before the
> transaction.
> This would reduce a lot of risks which can happen when using fake
> transaction nesting
> within one process together with nested event loops.

How does this help?  The inner transaction would still fail, right?
Perhaps an example would help me see it?


More information about the samba-technical mailing list