BIND 10 #2609: SERVFAIL on all queries while b10-loadzone is running

[BIND 10 Development]

#2609: SERVFAIL on all queries while b10-loadzone is running
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  Unclassified  |  Tasks
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:2 jinmei]:
 > Hmm, actually, SQLite3 doesn't even allow read if there's a
 > transaction in which some write operations have been performed:
 > http://www.sqlite.org/faq.html#q5

 That is, indeed, stupid.

 > To solve this situation, I guess we need some tricky operation within
 > sqlite_accessor:
 >
 > - if it's for replacing the entire zone, don't start a transaction,
 >   but assign a new zone ID in the "zones" table (preventing it from
 >   matching actual queries accidentally).

 I think this would not only be much more complicated, but also slower. The
 sqlite3 library would `sync()` after each write and the poor disk could
 jump
 out of the case because of that.

 And, it would lower the chance of collision a bit, but it could probably
 still
 happen, if the write of some piece of data happens at the same time as
 request
 to read.

 Another option could be to use a separate database file for each zone,
 construct the new version into a new file and then rename the file. But
 that
 has obvious drawbacks too.

 > So, a higher level alternative is to declare that the SQLite3 data
 > source shouldn't be used for a huge zone.  In that case, we should add
 > support for another data source (using a database that has more
 > fine-grained locking) very soon, though.

 That sounds like less work and more useful than the workaround.

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