views:

330

answers:

2

In which cases to you need to watch out for Concurrency problems (and use lock for instance) in ASP.NET?

  • Are there 'best practises' around on this topic
  • Documentation?
  • Examples?
  • 'worst practises...' or things you've seen that can cause a disaster...?

I'm curious about for instance singletons (even though they are considered bad practise - don't start a discussion on this), static functions (do you need to watch out here?), ...?

+2  A: 

Since ASP.NET is a web framework and is mainly stateless there are very few concurrency concerns that need to be addressed.

The only thing that I have ever had to deal with is managing application cache but this is easily done with a cache-management type that wraps the .NET caching mechanisms.

Andrew Hare
Well, except for database concurrency issues. :)
BobbyShaftoe
A: 

One huge problem that caused us a lot of grief was using Modules vs. Classes in our main Web Service. This was before we really knew what we were doing and has since been fixed.

The big problem with using modules is that by default any module level variables are visible to every instance of the ASP worker process. We pass in multiple datasets and manipulate them then return them to the client. Because we were using modules the variables holding these datasets were getting corrupted by multiple calls occuring at one time.

This was not caught in testing and was difficult to reproduce until we figured out how to properly load test our web services. It took something like 10-20 requests per second before we could reproduce it accurately.

In the end, we just changed all the modules to classes, and then used those classes instead of calls to the modules, this cleared up this concurrency issue as each instantiated class had its own copy of the dataset in memory.

Josh W.