2010-10-15 14 views
4

J'ai commencé à utiliser le code AspProviders pour stocker mes données de session dans mon stockage de table.asp.net mvc azure "Erreur lors de l'accès au magasin de données!"

Je reçois de façon sporadique l'erreur suivante:

Description: Exception of type 'System.Web.HttpException' was thrown. INNER_EXCEPTION:Error accessing the data store! INNER_EXCEPTION:An error occurred while processing this request. INNER_EXCEPTION: ConditionNotMet The condition specified using HTTP conditional header(s) is not met. RequestId:0c4239cc-41fb-42c5-98c5-7e9cc22096af Time:2010-10-15T04:28:07.0726801Z StackTrace: System.Web.SessionState.SessionStateModule.EndAcquireState(IAsyncResult ar) System.Web.HttpApplication.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) INNER_EXCEPTION: Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(HttpContext context, String id, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 484 System.Web.SessionState.SessionStateModule.GetSessionStateItem() System.Web.SessionState.SessionStateModule.PollLockedSessionCallback(Object state) INNER_EXCEPTION: Microsoft.WindowsAzure.StorageClient.Tasks.Task 1.get_Result() Microsoft.WindowsAzure.StorageClient.Tasks.Task 1.ExecuteAndWait() Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry[T](Func`2 impl, RetryPolicy policy) Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(TableServiceContext svc, SessionRow session, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 603 Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider.ReleaseItemExclusive(HttpContext context, String id, Object lockId) in \Azure\AspProviders\TableStorageSessionStateProvider.cs:line 480 INNER_EXCEPTION: System.Data.Services.Client.DataServiceContext.SaveResult.d__1e.MoveNext()

Toute personne courir dans tout cela? La seule information utile que j'ai trouvé est-ce que je suis hésitant à faire:

If you want to bypass the validation, you can open TableStorageSessionStateProvider.cs, find ReleaseItemExclusive, and modify the code from:

svc.UpdateObject(session);

to:

svc.Detach(session);
svc.AttachTo("Sessions", session, "*");
svc.UpdateObject(session);

de here

Merci!

donc j'ai décidé de changer cela:

svc.UpdateObject(session); svc.SaveChangesWithRetries();

à ceci:

try { svc.UpdateObject(session);

svc.SaveChangesWithRetries(); 

} catch { svc.Detach(session); svc.AttachTo("Sessions", session, "*"); svc.UpdateObject(session);

svc.SaveChangesWithRetries(); 

}

Alors, je vais voir comment ça fonctionne ...

Répondre

9

Je J'ai également rencontré ce problème et après quelques recherches, il semble que cela arrive plus souvent quand vous avez plus d'une instance et que vous essayez de faire des appels en succession rapide dans la même session. (Par exemple, si vous aviez une zone de saisie automatique et des appels ajax à chaque pression de touche)

Cela se produit parce que lorsque vous essayez d'accéder aux données de session, tout d'abord le serveur Web prend un verrou sur cette session. Lorsque la requête est terminée, elle libère le verrou. Avec le fournisseur de service de table, il met à jour cet état de verrouillage en mettant à jour un champ dans la table. Ce que je pense est que Instance1 charge la ligne de session, puis Instance2 charge la ligne de session, Instance1 enregistre l'état de verrou mis à jour et quand Instance2 tente de sauvegarder l'état de verrou il obtient une erreur parce que l'objet n'est pas dans le même état comme quand il l'a chargé (le ETag ne correspond plus). C'est pourquoi le correctif que vous avez trouvé arrêtera l'erreur, car en spécifiant le "*" dans le fichier AttachTo, lorsque Instance2 tentera de sauvegarder le verrou, il désactivera la vérification ETag (et écrase les changements effectués par Instance1). Dans notre situation, nous avons modifié le fournisseur afin que nous puissions désactiver la session pour certains chemins (l'appel ajax qui nous donnait nos problèmes n'a pas besoin d'accéder aux données de session, ni le chargement des images) qui peut être une option pour vous en fonction de ce qui cause votre problème.

Malheureusement, le TableStorageSessionStateProvider fait partie des exemples de projets et n'est donc pas (autant que je sache, mais on me le dira volontiers autrement) officiellement supporté par Microsoft. Il a d'autres problèmes, comme le fait qu'il ne nettoie pas ses données de session une fois la session expirée, de sorte que vous vous retrouverez avec beaucoup de déchets dans la table de session et le conteneur blob que vous devrez nettoyer d'autres façon.

+0

vraiment bonne réponse @knightpfhor. Merci de votre aide! –