宁静的WCF服务和LINQ

Question

WCF Restful Webservice seems to be caching the LINQ data objects somehow.

The webservice is a WCF Restful Service build on .NET 4.0 and is currently running in my local ASP.net Dev Server.

I have a MSSQL 2008 database which contains a range of valid IP addresses which the webservice uses LINQ to validate against. The mechanism that validates the client IP against the acceptable IP range from the DB works successfully as independently tested.

SCENARIO: client IP is 127.0.0.1 valid IP range is: 127.0.0.0 to 127.0.0.5

I perform a GET request from Fiddler to the webservice and it works as it should, by giving me back a nice 200 status code. I then change the range in the DB to be 127.0.0.0 to 127.0.0.0 and still receive a 200 status code when I should be receiving a 401 status code. I then go to Visual Studio and simply save a file (without any modifications) and return to Fiddler and reissue the request and I now get the desired 401 status code.

In the web service I am setting the Cache-Control and Pragma headers to "no-cache" which is present in the response:

HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Fri, 30 Jul 2010 16:12:56 GMT
X-AspNet-Version: 4.0.30319
Pragma: no-cache
Content-Length: 1121680
Cache-Control: no-cache
Content-Type: application/xml; charset=utf-8
Connection: Close

or..

HTTP/1.1 401 Unauthorized
Server: ASP.NET Development Server/10.0.0.0
Date: Fri, 30 Jul 2010 16:26:48 GMT
X-AspNet-Version: 4.0.30319
Pragma: no-cache
Content-Length: 88
Cache-Control: no-cache
Content-Type: application/xml; charset=utf-8
Connection: Close

It seems to me that something in the LINQ process is caching the data that it originally got back from the first request and is not returning to the DB for each subsequent request. Once I save any file on the webservice, it causes recompilation of the service and thus performs another lookup to get the data.

Answer 1

Are you able to test your LINQ-to-SQL call directly, without going through the web service, just to verify that LINQ-to-SQL may be performing caching for you?

Also, here's a link to an issue that's similar to yours, and requires that you disable object tracking. The default value of this property on your data context is true . The relevant section of the post:

Your solution is to disable object tracking (caching for LINQ) of the data context like so. myContext.ObjectTrackingEnabled = false;

Hope this helps!