I’m experiencing a problem with a Classic ASP application I’m maintaining (the architect is long gone). Each customer site gets a virtual directory that corresponds to their database name – for example, http://www.site.com/Foo would be a site for customer Foo, and their database would also be named Foo. 1:1 mapping, very clear.
Let’s say that there’s also http://www.site.com/Bar. The error I’m getting very occasionally, under at least moderate load, is that POST requests to /Bar are being saved in the /Foo database.
It’s worth noting here that the save action is subbed out to a .NET component instantiated with a Server.CreateObject call. This .NET class instance uses
System.EnterpriseServices.ContextUtil.GetNamedProperty("Request");
to get a handle to the current request. The .NET code constructs everything about the save action based on this request.
My working theory is that somehow, System.EnterpriseServices.ContextUtil and the .asp page that created the .NET component have different opinions about what the current request is. Is this possible? I seem to have the idea that requests were handled one at a time, but I don’t seem to be able to find an explicit answer to that.
I have tried putting all virtual directories into a single app pool, and each customer with their own – the problem occurs either way.
My only other idea is that somehow a database connection pool item is being reused incorrectly, but the database connections are created with the database name as part of the
connection string, so I find that to be extremely unlikely.
The server is running IIS 6, the database server is SQL Server 2000. Upgrade plans are already underway.
This appears to have been a database connection pool issue.
We were ale to identify that this error, a row of data going into the wrong database, would only occur in one case:
When those requests happen milliseconds apart, that’s when we saw the error.
We refactored the code to reduce the number of inserts being performed per loop, which has dramatically reduced the number of occurrences of this error, although we do still see it rarely.