2010-07-30 6 views
1

J'ai rencontré un problème intéressant avec le Webservice Restful WCF que j'écris. Il semble mettre en cache les objets de données LINQ en quelque sorte. Je vais essayer d'expliquer ...Service WCF reposant et LINQ

Ceci est ma première incursion dans webservices et ne suis pas un expert LINQ donc si je suis pauvre à expliquer cette s'il vous plaît nu avec moi ...

Webservice est un WCF Restful Service construit sur .NET 4.0 et est actuellement en cours d'exécution dans mon ASP.net Dev Server local.

J'ai une base de données MSSQL 2008 qui contient une plage d'adresses IP valides sur lesquelles le service Web utilise LINQ pour la validation. Le mécanisme qui valide l'adresse IP du client par rapport à la plage d'adresses IP acceptable de la base de données fonctionne correctement en tant que test indépendant.

SCÉNARIO: client IP est 127.0.0.1 plage IP valide est: 127.0.0.0 à 127.0.0.5

-je effectuer une requête GET de Fiddler au WebService et cela fonctionne comme il se doit, en me donnant retour un bon code d'état 200. Je modifie ensuite la plage dans la base de données pour être 127.0.0.0 à 127.0.0.0 et toujours recevoir un code d'état 200 quand je devrais recevoir un code d'état 401. Je vais ensuite dans Visual Studio et enregistre simplement un fichier (sans aucune modification) et retourne à Fiddler et relance la demande et maintenant je reçois le code de statut 401 désiré.

Dans le service Web que je suis en train de les en-têtes Cache-Control et Pragma à "no-cache", qui est présent dans la réponse:

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 

ou ..

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 

Il semble pour moi, quelque chose dans le processus LINQ met en cache les données qu'il a récupérées à l'origine à partir de la première requête et ne retourne pas à la base de données pour chaque requête suivante. Une fois que j'ai enregistré n'importe quel fichier sur le webservice, il provoque la recompilation du service et effectue ainsi une autre recherche pour obtenir les données.

Quelqu'un a déjà vu ce genre de situation avant?

+0

Votre base de données peut-elle mettre en cache les résultats? Vous souhaiterez peut-être vous connecter et voir ce qui se trouve dans l'objet de données LINQ, pour affiner s'il se trouve dans la couche de base de données ou quelque part plus haut dans la pile. –

Répondre

0

Etes-vous capable de tester votre appel LINQ-to-SQL directement, sans passer par le service Web, juste pour vérifier que LINQ-to-SQL peut effectuer la mise en cache pour vous?

En outre, voici un link pour un problème similaire au vôtre, et vous devez désactiver le suivi des objets. La valeur par défaut de cette propriété sur votre contexte de données est true. La section pertinente du poste:

Votre solution est de désactiver le suivi objet (mise en cache pour LINQ) du contexte de données comme ainsi. myContext.ObjectTrackingEnabled = false;

Espérons que cela aide!

+0

Man I love Stackoverflow ... mettre la propriété "objecttrackingenabled" à false a résolu mon problème. Merci beaucoup!!! – nokturnal

+0

Pas de problème! Heureux que ça marche pour toi !! –

+0

Merde, je suppose que cela rend les données en lecture seule. Je vais aussi avoir besoin d'insérer des données afin que jette une clé dans les engrenages .. – nokturnal

Questions connexes