2008/5/9 valantina arumugam <[EMAIL PROTECTED]>: > Yes. It's a tradeoff between consistency and > up-to-date information. Finally we have to give up one. > > ------------------------- > > Even if we increase the caching time, We can expect a walk req. just before > the expiry of caching time which will lead to refresh of table & > inconsistent data if any inst. add/remov-ed.
One final thought. You could try using a fairly generous cache timeout. Then add code to the end of the handler to detect when a GETNEXT request runs off the end of the table, and invalidate the cache. That would then mean that a subsequent request (even if it was within the nominal cache lifetime) would trigger a fresh loading of the data. Thought that wouldn't protect against overlapping walks, of course. When the first walk finished, the next step in the second one would then trigger a fresh reload, even if it was already part way through. As I indicated yesterday, there are no easy answers here :-( Dave ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
