BIND 10 #1212: Implement IXFR-in

[BIND 10 Development]

#1212: Implement IXFR-in
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  stephen                            |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20111011
  blocker                            |            Resolution:
                  Component:  xfrin  |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  12
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 jelte]:

 > In general this looks like a reasonable breakdown.
 >
 > I do wonder about the commit-per-100-'diffs' though, but maybe i
 misunderstand that specific part of your description.

 It's not *commit*-per-100, but *apply*-per-100.  What *apply* does is
 to start a new transaction (if not yet started) and apply the diffs
 under the transaction (in the database case by issuing SQL statements,
 for example), but it doesn't perform "commit" yet.

 So, *apply*-per-100 means we delay starting a transaction until we
 have 100 diffs (or have full diffs for a single SOA-SOA difference if
 they are smaller than 100).  This also means if the entire diff
 contain multiple RRs of the same RRset we may be able to benefit from
 combining them before actually applying the diff to the underlying
 data source (this part wouldn't be a big deal for DB-based data
 source, though, because we apply the diff per RR anyway, and so the
 total number of necessary SQL statements won't be different).

 This behavior is simply derived from the BIND 9 implementation (and I
 don't know the rationale of the magic number of 100).  If we don't
 like it or we think it's a premature optimization, we could skip that
 in our initial implementation.

 > One per soa->soa I can understand (as this reflects one complete
 change), but doing intermediate commits may leave the zone in an
 inconsistent state even without a second writer (if there is a failure
 after it). OTOH if we don't have onle one big transaction it may protect
 us from those, but one might run into global database transaction
 timeouts...

 Exactly, this tradeoff is what I was not sure either.  For our initial
 experimental implementation (which would be more for a proof of
 concept than for production use), either approach should be okay.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1212#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development