views:

60

answers:

2

I have a web application that uses LINQ-to-SQL. It has a very strange issue, where a LINQ command retrieves the data that is supposed to be returned by another, totally different query that runs in a different thread. What could be the cause of this?

Specifically, a user accesses the application from his machine, opening a certain page. At the same time, another user accesses a different page from his (different) machine. One of the queries throws an exception, while the other returns the data of the first one, which comes from a very different table!

The case is always reproducible, whenever we stress the application with these two users. I've checked but I don't see any shared variables of any kind. What else could the problem be? What should I be looking for?

Your help is really appreciated.

+1  A: 

Sounds like a connection is being reused. Make sure not to cache those and always create and release them properly, such as in this sample.

Lucero
That's what I've been trying to investigate most of the day, but in vain. I've even tried to create a new `DataContext` with every request (for one of the pages), but this didn't correct the issue. Do you have a suggestion on where else to look?
Hosam Aly
You don't want to re-create the `DataContext` on each call, as this should pretty much be a "singleton". That said, what code you you use to connect to the database?
Lucero
The `DataContext` used to be injected (using Unity), but I just changed it for the purposes of testing. To connect to the database I simply create a `DataContext` with a `SqlConnection` that takes the connection string. However, there is another (older) part of the application that use ADO.NET directly, every time creating (and closing) a new connection.
Hosam Aly
Are you re-creating the connection for each call? If not, that is your problem. From the `DataContext` constructor MSDN docs: *A `DataContext` opens and closes a database connection as needed if you provide a closed connection or a connection string. In general, you should never have to call `Dispose` on a `DataContext`. If you provide an open connection, the `DataContext` will not close it. Therefore, do not instantiate a DataContext with an open connection unless you have a good reason to do this.*
Lucero
A: 

You sure this isn't a session issue rather than a linq issue? Data requested from one asp.net session but passed over to another sounds like something's getting mixed up there.

Frank Tzanabetis