C# Programming
04-15-2009, 12:40 AM
First of all, I know the standard answer to this question is "If you need to know, you're doing it wrong", but I really do need to know!
Long story short, I have a caching mechanism in a web service (IIS 6) that can cache thousands of items in memory and return them almost instantly, without requiring a trip to the main datastore.
However, when the cached items expire they need to be refetched from the datastore, but only one caller can be executing the 'fetch' code at a time (or else it runs into all sorts of horrible race conditions and deadlocks). All the other callers must either wait for the first thread to update the cache (if the item is not found in the cache) or simply return the cached item while it is being updated in the background.
Each data item contains its own ManualResetEvent, which it uses to block while the cached item is updated. By giving each dataitem its own ManualResetEvent, I can allow other data items to be fetched without blocking them - the only calls that are blocked are those for the *exact* item that has expired.
My concern is that I will run out of handles for the data items, since each item has its own ManualResetEvent, and there could potentially be tens of thousands of data items. Do I need to worry about this, or should I try to come up with an alternate implementation?
Perhaps I could use a pool of ManualResetEvents that can be assigned to items as needed, similar to the way database connection pooling works? This is probably a "better" implementation, but it is more complex and harder to debug...
Thanks for your help http://www.barakasoft.com/script/Forums/Images/smiley_smile.gif
The StartPage Randomizer (http://www.StartPageRandomizer.com/) - The Windows Cheerleader (http://windowscheerleader.com/) - Twitter (http://twitter.com/miszou)
modified on Tuesday, April 14, 2009 4:14 PM
Long story short, I have a caching mechanism in a web service (IIS 6) that can cache thousands of items in memory and return them almost instantly, without requiring a trip to the main datastore.
However, when the cached items expire they need to be refetched from the datastore, but only one caller can be executing the 'fetch' code at a time (or else it runs into all sorts of horrible race conditions and deadlocks). All the other callers must either wait for the first thread to update the cache (if the item is not found in the cache) or simply return the cached item while it is being updated in the background.
Each data item contains its own ManualResetEvent, which it uses to block while the cached item is updated. By giving each dataitem its own ManualResetEvent, I can allow other data items to be fetched without blocking them - the only calls that are blocked are those for the *exact* item that has expired.
My concern is that I will run out of handles for the data items, since each item has its own ManualResetEvent, and there could potentially be tens of thousands of data items. Do I need to worry about this, or should I try to come up with an alternate implementation?
Perhaps I could use a pool of ManualResetEvents that can be assigned to items as needed, similar to the way database connection pooling works? This is probably a "better" implementation, but it is more complex and harder to debug...
Thanks for your help http://www.barakasoft.com/script/Forums/Images/smiley_smile.gif
The StartPage Randomizer (http://www.StartPageRandomizer.com/) - The Windows Cheerleader (http://windowscheerleader.com/) - Twitter (http://twitter.com/miszou)
modified on Tuesday, April 14, 2009 4:14 PM