BIND 10 trac1261, updated. 95cbc4efbaab12b66852ede318cb9af0d3f8780b [1261] added more explanation about commit timing

[BIND 10 source code commits]

The branch, trac1261 has been updated
       via  95cbc4efbaab12b66852ede318cb9af0d3f8780b (commit)
      from  3898b36a132fe44e51cc99674104d9e1f0d35d36 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 95cbc4efbaab12b66852ede318cb9af0d3f8780b
Author: JINMEI Tatuya <jinmei at isc.org>
Date:   Thu Oct 6 10:47:47 2011 -0700

    [1261] added more explanation about commit timing

-----------------------------------------------------------------------

Summary of changes:
 src/bin/xfrin/xfrin.py.in |   32 ++++++++++++++++++++++++++++++++
 1 files changed, 32 insertions(+), 0 deletions(-)

-----------------------------------------------------------------------
diff --git a/src/bin/xfrin/xfrin.py.in b/src/bin/xfrin/xfrin.py.in
index 1ffd841..f8b310a 100755
--- a/src/bin/xfrin/xfrin.py.in
+++ b/src/bin/xfrin/xfrin.py.in
@@ -168,6 +168,38 @@ class XfrinState:
                                    V
                                 IXFREnd
 
+    Note that changes are committed for every "difference sequence"
+    (i.e. changes for one SOA update).  This means when an IXFR response
+    contains multiple difference sequences and something goes wrong
+    after several commits, these changes have been published and visible
+    to clients even if the IXFR session is subsequently aborted.
+    It is not clear if this is valid in terms of the protocol specification.
+    Section 4 of RFC 1995 states:
+
+       An IXFR client, should only replace an older version with a newer
+       version after all the differences have been successfully processed.
+
+    If this "replacement" is for the changes of one difference sequence
+    and "all the differences" mean the changes for that sequence, this
+    implementation strictly follows what RFC states.  If this is for
+    the entire IXFR response (that may contain multiple sequences),
+    we should implement it with one big transaction and one final commit
+    at the very end.
+
+    For now, we implement it with multiple smaller commits for two
+    reasons.  First, this is what BIND 9 does, and we generally port
+    the implementation logic here.  BIND 9 has been supporting IXFR
+    for many years, so the fact that it still behaves this way
+    probably means it at least doesn't cause a severe operational
+    problem in practice.  Second, especially because BIND 10 would
+    often uses a database backend, a larger transaction could cause an
+    undesirable effects, e.g. suspending normal lookups for a longer
+    period depending on the characteristics of the database.  Even if
+    we find something wrong in a later sequeunce and abort the
+    session, we can start another incremental update from what has
+    been validated, or we can switch to AXFR to replace the zone
+    completely.
+
     This implementation uses the state design pattern, where each state
     is represented as a subclass of the base XfrinState class.  Each concrete
     subclass of XfrinState is assumed to define two methods: handle_rr() and