I'm trying to cache some information that I've retrieved from a database. I've decided to use a static List<> member to store the information. I know from my experience with List<> in multithreaded applications that I need to protect access to it with the lock statement. Do I treat any code in my Asp.Net code the exact same way? Will the lock statement still work?
+2
A:
Lock will work. Be aware that if there are multiple worker processes, you will end up with multiple versions of the list. Each of them will be protected by its own lock.
A pretty real danger here is that if you fail to release the lock, your entire web application might hang. A user might get disconnected while your ASP.NET page is executing; so be careful of exceptions thrown at unexpected times.
Andomar
2009-06-14 18:31:33
Is that possible? I was under the impression that lock() {} guarantees that the lock will be released. Also, do you know or at least know where I can find out how often ASP.Net will create a new thread for a request versus an entirely new process?
Spencer Ruport
2009-06-14 18:40:55
Agree lock() {} would guarantee the lock release. You can configure the number of processes in IIS, in the Application Pool settings, under "Maximum Worker Processes". The default is 1, which means there will only be one process.
Andomar
2009-06-14 18:43:34
Alright thanks! +1
Spencer Ruport
2009-06-14 18:45:47
I ended up going with this route. I know the behavior of the static classes and I didn't see the purpose in using the Cache class since it only seemed to add another layer of complexity.
Spencer Ruport
2009-06-20 01:32:29
+4
A:
A lock statement around List method's would definitely work but if you need caching functionality in your ASP.NET application I would recommend you using Cache class which is adapted to this functionality.
Darin Dimitrov
2009-06-14 18:33:30
A:
It depends upon whether you're going to modify the List. Here's a good discussion of this subject: Do i need a lock on a list? C#
DOK
2009-06-14 18:34:02