[bind10-dev] xfrin (was Re: revised/refactored data source design proposal)

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/03/2011 04:22 PM, Michal 'vorner' Vaner wrote:
>> - xfrin has its own DataSourceClient for the in-memory data source.
>>   When it performs IXFR, it stores the diff to the separate DB
>>   storage, and also updates the in-memory image (the latter would be
>>   necessary to eventually dump the latest zone to a separate file).
> 
> I always thought of XFRs not having the in-memory loaded at all, working
> on top of the backend DB. Only the auth would do some kind of atomic
> reload/update. I didn't therefore think about this much. But if we can
> atomically reload from DB, we can atomically reload from notification and XFRs
> probably can afford to lock their copy completely even if we don't come up with
> something more clever.
> 

I think the way to handle transfers-in are backend-specific, and that xfrin
should not be aware of the way any specific backend handles this; so it would
use the Updater classes described here. For ixfr and dynamic dns, these classes
do need read access to existing data, so for some backends (like in-memory), i'm
afraid this does mean 'loading' them (or sharing them with auth, if possible).
Like you, I do think it should update the persistent storage first, then ping
auth to reload if necessary. But apart from the ping, this updating should be
done by the backend implementation, not by xfrin itself.

Not only is this cleaner from the xfrin point of view, it also leaves much more
flexibility on datasource design (like, one could even imagine having several
in-memory datasources with their own strengths and drawbacks).

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3t7HcACgkQ4nZCKsdOncWDkgCeP7OAD1GeQPP8eapAUxLUAnaZ
20UAnjr978ZzSxzvhXMQHUvLj7v+Hlc4
=dV4R
-----END PGP SIGNATURE-----