[bind10-dev] Refactored data source - design

[JINMEI Tatuya / 神明達哉]

Catching up an old thread...

At Fri, 08 Jul 2011 18:51:14 +0100,
Stephen Morris <stephen at isc.org> wrote:
> 
> Some comments on http://bind10.isc.org/wiki/DataSourceDesign (as
> requested in ticket #817)
> 
> * I have no problem in keeping the DB backend as dumb as possible. The
> abstract DataBaseDataSourceClient with a concrete implementation for
> each database would seem to achieve that.  Also, the operations
> illustrated in the DataBaseConnection class seem high-level enough to
> allow their replacement with calls to database stored procedures (for
> databases that support them) if doing so would result in a performance
> improvement.

Okay, good.

> * Agree with the idea that a different data source is used for each
> class, but what do we do about "version.bind" queries? Will we treat
> these as special case or will we supply a stub "CH" class data source to
> handle them?

Actually, I didn't think much about it although I was aware that was a
missing part.  Considering all specific DB backend will eventually be
optional (= selectable at build time or, probably preferably, becoming
loadable modules), however, I guess we'll need some form of the
current "static data source".  I think that should be pretty easy to
implement, and it would be a good demonstration of how general the
high level interface is (or isn't).

> * Prefer ZoneFinder to ZoneHandle. (The latter seems to suggest that it
> is some class holding a handle to a zone served by the authoritative
> server.)

Okay, I have no problem with it, and updated the wiki page
accordingly.  One possible drawback of this naming is that
"ZoneFinder" may sound something "finding a zone" rather than
"finding an RR(set) in a zone".  Do you think this name could be
confusing that way?

> * Regarding updates, am I right in remembering that we made the decision
> to always have a database back end, and that updates would be applied to
> that and loaded into cache? (It would be useful to state that early on
> as it gives some context to the design.)

Actually I misunderstood or misremembered the conclusion at that time,
but, yes, you're right according to the meeting minutes. (I'm not sure
if I understand the "loaded into cache" part though).  I've not yet
come up with a complete image of how to realize that concept with the
proposed design, but I guess it would look something like this:

- An in-memory data source client is configured with information of
  the underlying data source (which would be based on some real data
  base).
- When opening, the in-memory client will internally hold another
  client to get access to the underlying data source, and load the
  content of a specific zone into memory using a zone iterator.
- xfrin/update will directly hold a client to the underlying data
  source and make updates on the real data base via that client.
- to propagate the updates to auth, xfrin/update notifies auth of the
  need for update, and then auth auth will reload the entire new zone.
  This is not scalable, but would be okay for early experiments.  In
  later versions we'll need to design and implement more scalable
  solution (this may be related to the shared memory approach we
  discussed in the context of the multi core support)

> * At some time we need to decide if we are going the multi-thread or
> multi-process route.  This probably won't impact on the data source
> design, but I would anticipate that it will have an impact on the design
> of the hotspot cache.

As we discussed in the separate (email) thread, yes.  I think we'll
begin with separate caches for separate threads or processes.  One big
question is whether the cache may eventually be shared by multiple
threads or processes.  If the answer is yes, we'll have to introduce
some form of mutex.  Right now, we still don't know how exactly we
support multi cores, so this point is still open, too.

---
JINMEI, Tatuya