Stratégies d'accès simultané au cache strictes vs non strictes de NHibernate

Question

Cette question concerne la différence entre les stratégies d'accès simultané au cache ReadWrite et NonStrictReadWrite pour le cache de second niveau de NHibernate.

Si je comprends bien, la différence entre ces deux stratégies est pertinente lorsque vous avez un cache distribué répliqué - sans restriction, rien ne garantit qu'un cache a exactement la même valeur qu'un autre cache, même s'il est strict. read / write devrait - en supposant que le fournisseur de cache effectue le verrouillage distribué approprié.

La partie que je ne comprends pas est la pertinence de la distinction stricte / non stricte lorsque vous avez un seul cache ou un cache distribué partitionné (non répliqué). Peut-il être pertinent? Il me semble que dans les scénarios non répliqués, le cache d’horodatage garantira que les résultats obsolètes ne seront pas servis. Si cela peut être pertinent, j'aimerais voir un exemple.

Answer 1

Ce que vous supposez être juste, dans un environnement cible / thread unique, il y a peu de différence. Cependant, si vous regardez les fournisseurs de cache, il se passe un peu, même dans un scénario multithread.

La manière dont un objet est remis en cache à partir de son état modifié est différente dans l'état non strict. Par exemple, si votre objet est beaucoup plus lourd à recharger mais que vous aimeriez le faire après une mise à jour au lieu de laisser le prochain utilisateur avec la facture, vous verrez des performances différentes avec strict vs non-strict. Par exemple: non-strict vide simplement un objet du cache après une mise à jour ... le prix est payé pour l'extraction sur l'accès suivant au lieu d'un gestionnaire d'événements post-mise à jour. Dans le modèle strict, le re-cache est pris en charge automatiquement. Une chose similaire se produit avec les insertions, non stricte ne fera rien là où strict ira derrière et chargera le nouvel objet inséré dans le cache.

En mode non strict, vous avez également la possibilité d’une lecture sale, car le cache n’est pas verrouillé au moment de la lecture, vous ne verrez pas le résultat de la modification d’un élément par l’un des autres threads. En mode strict, la clé de cache de cet élément se verrouillerait et vous seriez retenu, mais le résultat le plus récent serait absolu.

Ainsi, même dans un environnement cible unique, s'il existe un grand nombre de lectures / modifications simultanées sur des objets, vous avez la possibilité de voir des données qui ne sont pas vraiment précises.

Cela devient bien sûr un problème lorsqu'un enregistrement est effectué et qu'un écran d'édition est en train de se charger: la personne qui pense modifier la dernière version de l'objet ne le fait vraiment pas, et elle risque une mauvaise surprise lorsqu'elle essayez de sauvegarder les modifications apportées aux données périmées qu’elles ont chargées.

Answer 2

J'ai créé un message ici expliquer les différences. S'il vous plaît jeter un oeil et n'hésitez pas à commenter.