[bind10-dev] Datasource discussion

[Shane Kerr]

All,

On Wed, 2010-01-13 at 11:31 +0100, Jelte Jansen wrote:
> We started out talking a bit about updates, and transactions for that.
> Michael suggested earlier that we could look into using diffs; this
> could take the form of dynamic dns updates, i.e. a set of prerequisites,
> and a set of changes. Then we wouldn't need a full transaction
> interface, as the update methods can take care of that.

DNS is very "fuzzy" in general, so maybe not using transactions is
indeed the way to go. It might allow us to do faster processing on
updates, if we can lock only part of the tree based on knowing what all
operations in a set are. OTOH, techies are familiar with transactions,
and understand their benefits and limitations.

One specific problem with this approach is that it doesn't work so good
with queries, unless you introduce a basic query which says something
like "give me the NS RRSET for foo.example, plus also any A or AAAA
RRSET that you have for the name server names we're authoritative for".
Otherwise your server can end up replying with an NS RRSET that has
non-existent A/AAAA records even if the administrator never configured
it in such a way. Not a *huge* problem I suppose, but we need to at
least recognize and document the possibility.

One question I have is how much trouble it will be to re-factor a system
that doesn't use transactions into one that does. One thing is that you
will need to update your code to pass the transaction handle around
(assuming for some crazy reason we don't use the far-superior model I
presented which doesn't use the begin_transaction() method as a factory
for creating transaction objects). ;) Another thing is that if you don't
have transactions, you sometimes end up doing things that are not
necessary if you do (like re-trying failed operations, being very
careful about ordering of operations, and so on).

I mention re-factoring because I think we have two options:

     1. Start off without transactions, understanding that we will need
        to re-factor the code if we add them later.
     2. Start off with transactions, but have them be null methods in
        initial data source implementations.

Maybe we need to ask the question "how important is always giving a
completely consistent answer?" to users? Or rather, "how much
performance would you be willing to give up to get a completely
consistent answer?"

--
Shane