Modèles de concurrence (mise en cache d'AppFabric 1.1)

L'architecture de Microsoft AppFabric 1.1 pour Windows Server permet à tout client de cache d'accéder ouvertement à toutes données mises en cache s'il dispose de l'accès au réseau et des paramètres de configuration appropriés. Cela constitue un défi en matière de sécurité et de concurrence.

Pour réduire les risques liés à la sécurité, les clients de cache, les serveurs de cache et le serveur de source de données primaire doivent être membres du même domaine et déployés dans le périmètre d'un pare-feu. Il est également vivement conseillé de sécuriser les fichiers de configuration d'application sur les clients de cache.

Pour aider votre application à gérer les problèmes de concurrence, AppFabric prend en charge des modèles d'accès concurrentiel optimiste et pessimiste. Pour plus d'informations sur les méthodes disponibles pour l'alignement sur ces modèles, consultez la rubrique Méthodes d'accès concurrentiel.

Modèle d'accès concurrentiel optimiste

Dans le modèle d'accès concurrentiel optimiste, les mises à jour des objets mis en cache ne prennent pas de verrous. Au lieu de cela, quand le client de cache obtient un objet du cache, il en obtient et stocke également la version actuelle. Si une mise à jour est requise, le client de cache envoie la nouvelle valeur pour l'objet en même temps que l'objet version stocké. Le système met l'objet à jour uniquement si la version envoyée correspond à la version actuelle de l'objet en cache. Chaque mise à jour d'un objet modifie son numéro de version, ce qui empêche la mise à jour d'écraser les modifications apportées par quelqu'un d'autre.

L'exemple présenté dans cette rubrique illustre la manière dont l'accès concurrentiel optimiste maintient la cohérence des données.

Exemple

Dans cet exemple, deux clients de cache (cacheClientA et cacheClientB) sur deux serveurs d'applications séparés tentent de mettre à jour le même objet mis en cache nommé RadioInventory.

Temps zéro : les deux clients extraient le même objet

Au temps zéro (T0), les deux clients de cache instancient une classe DataCacheItem pour capturer l'objet mis en cache qu'ils ont l'intention de mettre à jour, ainsi que des données supplémentaires associées à cet objet, telles que des informations de version et de balise. Cela est illustré dans le diagramme et l'exemple de code suivants.

'cacheClientA pulls the FM radio inventory from cache
Dim clientACacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientA As DataCache = _
        clientACacheFactory.GetCache("catalog")
Dim radioInventoryA As DataCacheItem = _
        cacheClientA.GetCacheItem("RadioInventory", "electronics")

'cacheClientB pulls the same FM radio inventory from cache
Dim clientBCacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientB As DataCache = _
       clientBCacheFactory.GetCache("catalog")
Dim radioInventoryB As DataCacheItem = _
        cacheClientA.GetCacheItem("RadioInventory", "electronics")

//cacheClientA pulls the FM radio inventory from cache
DataCacheFactory clientACacheFactory = new DataCacheFactory();
DataCache cacheClientA = clientACacheFactory.GetCache("catalog");
DataCacheItem radioInventoryA = 
    cacheClientA.GetCacheItem("RadioInventory","electronics");

//cacheClientB pulls the same FM radio inventory from cache
DataCacheFactory clientBCacheFactory = new DataCacheFactory();
DataCache cacheClientB = clientBCacheFactory.GetCache("catalog");
DataCacheItem radioInventoryB= 
    cacheClientA.GetCacheItem("RadioInventory", "electronics");

Notes

Bien que cet exemple obtienne les informations de version en utilisant la méthode GetCacheItem pour extraire l'objet DataCacheItem, il est également possible d'utiliser la méthode Get pour obtenir l'objet DataCacheItemVersion associé à l'élément de cache extrait.

Temps un : la première mise à jour réussit

Au temps un (T1), cacheClientA met à jour l'objet mis en cache RadioInventory avec une nouvelle valeur. Quand cacheClientA exécute la méthode Put, la version associée à l'élément de cache RadioInventory est incrémentée. À ce moment, cacheClientB a un élément de cache obsolète. Cela est illustré dans le diagramme et l'exemple de code suivants.

'at time T1, cacheClientA updates the FM radio inventory
Dim newRadioInventoryA As Integer = 155

cacheClientA.Put("RadioInventory", newRadioInventoryA, _
                 radioInventoryA.Version, "electronics")

//at time T1, cacheClientA updates the FM radio inventory
int newRadioInventoryA = 155;

cacheClientA.Put("RadioInventory", newRadioInventoryA, 
    radioInventoryA.Version,"electronics");

Temps deux : la deuxième mise à jour échoue

Au temps deux (T2), cacheClientB essaie de mettre à jour l'objet mis en cache RadioInventory en utilisant ce qui est désormais un numéro de version obsolète. Pour empêcher l'écrasement des modifications de cacheClientA, l'appel de la méthode cacheClientB Put échoue. Le client de cache génère un objet DataCacheException avec la propriété ErrorCode définie sur CacheItemVersionMismatch. Cela est illustré dans le diagramme et l'exemple de code suivants.

'later, at time T2, cacheClientB tries to 
'update the FM radio inventory, throws DataCacheException with
'an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
Dim newRadioInventoryB As Integer = 130

cacheClientB.Put("RadioInventory", newRadioInventoryB, _
                 radioInventoryB.Version, "electronics")

//later, at time T2, cacheClientB tries to 
//update the FM radio inventory, throws DataCacheException with
//an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
int newRadioInventoryB = 130;

cacheClientB.Put("RadioInventory", newRadioInventoryB,
    radioInventoryB.Version,"electronics");

Modèle d'accès concurrentiel pessimiste

Dans le modèle d'accès concurrentiel pessimiste, le client verrouille explicitement des objets pour exécuter des opérations. Les autres opérations demandant des verrous sont rejetées (le système ne bloque pas les demandes) jusqu'à ce que les verrous soient libérés. Quand des objets sont verrouillés, un handle de verrou est renvoyé sous la forme d'un paramètre de sortie. Le handle de verrou est obligatoire pour déverrouiller l'objet. Si l'application cliente s'arrête avant la libération d'un objet verrouillé, des délais d'expiration sont fournis pour libérer les verrous. Les objets verrouillés ne sont jamais expirés mais peuvent expirer immédiatement après leur déverrouillage si le délai d'expiration est écoulé. Pour plus d'informations sur les méthodes utilisées avec le modèle d'accès concurrentiel pessimiste, consultez la rubrique Méthodes d'accès concurrentiel.

Notes

Les opérations de fractionnement des transactions ne sont pas prises en charge L'application utilisant le cache est responsable de la détermination de l'ordre des verrous et de la détection des blocages éventuels.

Avertissement

Tout client de cache peut remplacer les objets verrouillés dans le cache avec la méthode Put. Les applications prenant en charge le cache sont responsables de l'utilisation cohérente de l'opération PutAndUnlock pour les éléments qui utilisent le modèle d'accès concurrentiel pessimiste.

Voir aussi

Concepts

Méthodes d'accès concurrentiel
Diagramme de l'architecture physique de mise en cache d'AppFabric (mise en cache d'AppFabric 1.1)
Diagramme de l'architecture logique de mise en cache d'AppFabric (mise en cache d'AppFabric 1.1)
Développement d'un client de cache

  2012-03-05