CODEWITHSUNDEEP
asp.netconcurrency
Lieven Cardoen
Lieven Cardoen

Reputation: 25979

Concurrency ASP.NET best-practices worst-practices

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

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?), ...?

Upvotes: 1

Views: 886

Answers (2)

Josh Weatherly
Josh Weatherly

Reputation: 1740

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.

Upvotes: 0

Andrew Hare
Andrew Hare

Reputation: 351748

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.

Upvotes: 2

Related Questions