tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

Christian Ambach ambi at
Thu May 10 05:46:08 MDT 2012

On 05/10/2012 07:08 AM, Rusty Russell wrote:

 > Since the transition is taking longer than we'd hope (and turning tdb2
 > off again as proposed by Christian isn't going to help), perhaps we
 > should change this and rename everything to tdb2*.  It's not *that*
 > big a change to SAMBA in practice.

But what about outside users of libtdb? There seem to be various 
projects that rely on libtdb. If we now change the semantics behind the 
existing API, those projects will have to adjust their code as well.
We will have to support libtdb for a while for all of the projects 
depending on it until they have adopted to the TDB2 API.

So my proposal would be to:
1. leave libtdb as it is today
1a) make tdb the default again in the build
2. introduce tdb2 as new library with the new API
2a) add it to the autoconf build
2b) maybe leave out the tdb_compat part?
3. create a dbwrap_tdb2 layer that will take care of the subtle changes 
in a single place for source3
3a) switch source3 code place by place to the new dbwrap, start with the 
ones that will benefit from tdb2 first
4. adopt the source4 pieces (I am not familiar with those)
5. make tdb2 the default in the build

And then piece by piece migrate existing code to use tdb2 and once all 
references have been removed, we'll need to encourage other projects to 
follow our approach.

I am not sure how to handle CTDB here: once source3 starts to explicitly 
request TDB2, CTDB will have to learn about it as well but we still need 
a fallback that can deal with tdb1 databases until databases are 
recreated after a complete cluster restart.


More information about the samba-technical mailing list