1 is not really an issue. Each request checks the cache. If it is not there,
it is updated so the next thread gets the updated copy. (for the most part -
there is a nasty concurrency issue that we'll tackle in 2)
2 you will need to wrap the cache object with a function that locks the
cache when it is being written. This will block other threads while the data
is updated. If the update is not frequent, this is not a problem. however,
if it is or if there are a lot of cache misses, you could bottle neck. One
solution is to lock on a string object that represents the cache. This is
much cheaper than locking on the cache object itself. so essentially, the
string represents the cache. you lock the string and update the cache. there
is some slight overhead but it fairs rather well under moderate loads - at
least better than locking the cache object itself.

Signature
Regards,
Alvin Bruney - ASP.NET MVP
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc
>I need to cache user data within an HttpModule so I've overloaded
>OnAuthenticate I retrieve the LOGON_USER server variable as the site must
[quoted text clipped - 14 lines]
> Regards
> Robert.
Robert Rolls - 26 Jun 2005 10:16 GMT
Is it acceptable to potentially stop other requests where the cache read
would be successful? I.e. two requests are being serviced simultaneously one
connection has requested files before and hence the cache will contain the
users AD data, the other connection data isn't in the cache but will now
lock the cache whilst the write occurs? This is probably on time where the
ReaderWriterLock may be an ideal candidate.
Regards
Robert.
>1 is not really an issue. Each request checks the cache. If it is not
>there, it is updated so the next thread gets the updated copy. (for the
[quoted text clipped - 30 lines]
>> Regards
>> Robert.