BIND 10 #192: Data source hotspot cache

[BIND 10 Development]

#192: Data source hotspot cache
-------------------------+--------------------------------------------------
 Reporter:  each         |        Owner:  each                                          
     Type:  enhancement  |       Status:  reviewing                                     
 Priority:  major        |    Milestone:  05. 3rd Incremental Release: Serious Secondary
Component:  b10-auth     |   Resolution:                                                
 Keywords:               |    Sensitive:  0                                             
-------------------------+--------------------------------------------------

Comment(by jinmei):

 Replying to [comment:9 each]:

 > Oops, a bunch of text got cut out by mistake.

 > > > Design: I don't think making this as a static is a good idea.

 > I have no particular objection to doing it the way you suggested, but I
 do think there's some advantage to code that does the right thing without
 being told.

 The fact that the user app of the data source doesn't have to be aware of
 a cache is indeed a plus.  I agree with that; however, that advantage is
 way too weak to justify troubles as a result of relying on an essentially
 global object.  But I realize which one is more substantial may be a
 matter of opinion, so, instead of explaining why essentially-global is so
 dangerous, I'm going to make a different style of argument.

 Actually, we already required the user app to prepare an app-specific
 object: an entry point to the data source.  In our auth server case, it's
 AuthSrvImpl::data_sources_, a !MetaDataSrc object.  With your logic (that
 these things should require some type of global object), we could/should
 also make this a static object defined in the data source module.  Putting
 this in another way, we can pass the cache information on the creation of
 the !MetaDataSrc, or if we really want to hide it from the app, we can let
 !MetaDataSrc create a cache within it unconditionally (but I actually
 think we'd rather let the app configure the cache explicitly.  I can
 easily think of an app that wants to disable the cache).  This way, we can
 make the cache common to all lookups for the app, still avoiding to have a
 singleton object.

 For a middle term plan, I'd suggest refactoring the current data
 source/query handle logic as we discussed before, so that we define a
 separate class of top level query handling instead of the monolithic
 hierarchy of the current data source variants.  (I thought we generally
 agreed with the idea)  Then we can create (or hide) the cache with the top
 level object.

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