1

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

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

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

khellang
  • 17,550
  • 6
  • 64
  • 84
Lieven Cardoen
  • 25,140
  • 52
  • 153
  • 244
  • Singletons are not considered bad practice in any circles I'm aware of. – Rex M Mar 24 '09 at 18:59
  • Well, if you google for it, a lot of people say different things. We use it all the time in Flex/WPF/Silverlight applications. In ASP.NET however, aren't they sort of BottleNecks? – Lieven Cardoen Mar 24 '09 at 20:17
  • @Lieven I agree with Rex, they aren't bottle necks unless you do something wrong with them - like designing them to require locks in a scenario like asp.net. Like you said, that's a different discussion. – eglasius Mar 24 '09 at 21:49
  • When do you need a lock in a singleton? If two threads call a function in a singleton, won't that always give problems? Or does each thread get its own stack for the function? And what about static variables used in the function? – Lieven Cardoen Mar 25 '09 at 07:18

2 Answers2

2

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
  • 344,730
  • 71
  • 640
  • 635
0

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 Weatherly
  • 1,710
  • 1
  • 15
  • 27