[Originally posted by jwatson3d]

I've just picked up this book and am working through it now. I have a specific
need which lead me to find the book and I'm hoping it'll help. I'm developing
a custom cache based upon the NameObjectCollectionBase. The cache will hold
custom, strongly-typed objects. I'm following the "pattern" of
System.Web.Cache and looking to build in automatic expiration and removal as
an option. My question is, if I use System.Threading.Timer to implement what
is the impact of having 100's of Timers waiting to expire the contents? What
if it's 1,000's of timers?, etc.

Alternately, I could create a worker thread from within a Windows Service to
periodically scan the cache looking for expired items to remove - not as
"tight" but maybe less strain on resources?

Does anybody have any thoughts, concerns, etc.?

[Originally posted by alan]

I would avoid a timer per object.

Two approaches come to mind:

1) Use a thread that expires the elements of the cache. Set it with a lower
priority so it works much like the GC thread.

2) Check the expiration when you pull the item from the cache. I suspect this
is how the ASP.NET cache object works. This is a little simpler but doesn't
remove things from the cache until someone asks for them.

It really depends on what's being cached and if their being removed from the
cache is critical. I think you should spend some time looking that the
Reader/Writer lock chapter of the book. I think you'll find it very
applicable.

Hope this helps,
Alan

[Originally posted by jwatson3d]

Thank you Alan. I will dig into the chapter (as well as the entire book!). I
"felt" that the timer thread pool approach was "heavy" and you've confirmed
that.

John