BIND 10 #2460: make ConfigurableClientList::getCachedZoneWriter thread safe

[BIND 10 Development]

#2460: make ConfigurableClientList::getCachedZoneWriter thread safe
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  data source   |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 This is a continuation of #2459.

 While the suggested solution in #2459 solves the immediate problem by
 a relatively simple patch, it's suboptimal performance-wise because
 getCachedZoneWriter() involves expensive DB accesses several times,
 some may be even blocking: one is findZone(), and the other is
 getIterator().  The latter is especially problematic in that it opens
 a new DB connection.

 Fortunately, getIterator() itself should be thread safe as long as
 `DatabaseAccessor::clone()` of the underlying DB accessor
 implementation is thread safe (which is the case for our SQLite3 version).

 So my suggested better (but requiring larger changes) solution is as
 follows:

 - extend `ConfigurableClientList` so the caller can know if a
   specified zone is "cached" (and no, I don't like to use
   `getDataSources()` for this purpose.  IMO it discloses too much
   internal details of the class and restricts future changes of the
   implementation).  One possibility is to extend find() (like
   extending exact_match_ to a generic flags).
 - revise getCachedZoneWriter() so it only looks for in-memory data
   sources.  findZone() on in-memory data source should be thread safe,
   so there's no risk of race here.  We'll need to extend
   findInternal() a bit to make this possible.
 - in b10-auth (or any other possible user of getCachedZoneWriter()),
   the builder thread first checks if it really needs to do reload
   using the first extension.  It protects this operation by the mutex.
   If it does, the builder calls the revised getCachedZoneWriter()
   without the protection of mutex.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2460>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development