This project is read-only.

Thread Safe

May 3, 2010 at 2:47 PM
Edited May 3, 2010 at 5:49 PM

Your cache implementation is not thread safe, you have no reader or writer locks on the get and set methods, by default the generic dictionary is also not thread safe, so what is the benefit using this instead of the caching mechanics ,

which is already coming out of box?


May 4, 2010 at 10:08 PM
Edited May 5, 2010 at 9:59 PM

One benefit it not having to have a reference to System.Web in assembly's outside of your web project (like a service layer). I believe this gives better control over caching at a method level rather than a controller / page level.

I believe that calls from the cache class are thread safe (but I am still a little unclear if i missed something?). I have placed locks in the CacheDictionaryHelper  and all calls on the dictionary from the Cache class are made by calling the helper methods where locks are placed.

I guess because the dictionary is exposed to the calling assembly so users could call on the default implementation of the dictionary rather than the cache methods which I agree is not thread safe (this is bad API design on my part! - I shouldn't expose the dictionary)

I have just made a branch where I have made the dictionary thread safe also.... let me know what you think? I believe it solved the issue.



May 19, 2010 at 9:07 PM

Fixed Now - Changes to the API for the RC release - so now should be completly thread safe....