2008/5/9 valantina arumugam :
> 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 :-(


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.
Net-snmp-users mailing list
Please see the following page to unsubscribe or change other options: