Modelos de simultaneidad (Almacenamiento en caché de Windows Server AppFabric)

La arquitectura de Windows Server AppFabric permite el acceso abierto a todos los datos en caché a cualquier cliente de caché con el acceso de red y las opciones de configuración adecuadas. Eso supone todo un reto de seguridad y concurrencia.

A fin de reducir los riesgos de seguridad, todos los clientes de caché, servidores de caché y el servidor de origen de datos principal deben pertenecer al mismo dominio y estar implementados dentro del perímetro del firewall. También es recomendable proteger los archivos de configuración de aplicación de los clientes de caché.

Para facilitar la concurrencia en la aplicación, AppFabric admite modelos de concurrencia optimistas y pesimistas. Si desea obtener información acerca de los métodos disponibles para alinearse con estos modelos, vea Métodos de simultaneidad (Almacenamiento en caché de Windows Server AppFabric).

Modelo de concurrencia optimista

En el modelo de concurrencia optimista, no se usan bloqueos en las actualizaciones de objetos en caché. Cuando el cliente de caché obtiene un objeto de la memoria caché, también obtiene y almacena la versión actual del objeto. En el momento de la actualización, el cliente de caché envía el nuevo valor del objeto, junto con el objeto de la versión almacenada. El sistema sólo actualiza el objeto si la versión enviada coincide con la versión actual del objeto en la memoria caché. Todas las actualizaciones de un objeto modifican su número de versión, lo que impide que una actualización sobrescriba los cambios de otra persona.

El ejemplo de este tema muestra cómo conserva la coherencia de datos la concurrencia optimista.

Ejemplo

En este ejemplo, dos clientes de caché (cacheClientA y cacheClientB) de dos servidores de aplicaciones distintos intentan actualizar el mismo objeto en caché, denominado RadioInventory.

Hora cero: ambos clientes recuperan el mismo objeto

A la hora cero (H0), ambos clientes de caché crean instancias en una clase DataCacheItem para obtener el objeto en caché que intentan actualizar, además de información adicional asociada al objeto en caché, como la versión y las etiquetas. El siguiente diagrama y ejemplo de código lo ilustran.

'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");

Nota

Aunque este ejemplo obtiene la información de la versión mediante el método GetCacheItem para recuperar el objeto DataCacheItem, también se puede usar el método Get para obtener el objeto DataCacheItemVersion asociado al artículo en caché recuperado.

Hora uno: se completa la primera actualización

A la hora uno (H1), cacheClientA actualiza el objeto en caché RadioInventory con un valor nuevo. Cuando cacheClientA ejecuta el método Put, aumenta el número de versión asociado al elemento en caché RadioInventory. En este momento, cacheClientB tiene un elemento de caché obsoleto. El siguiente diagrama y ejemplo de código lo ilustran.

'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");

Hora dos: la segunda actualización devuelve un error

A la hora dos (H2), cacheClientB intenta actualizar el objeto en caché RadioInventory a través de un número de versión obsoleto. Para impedir que se sobrescriban los cambios de cacheClientA, el método cacheClientBPut devuelve un error. El cliente de caché produce un objeto DataCacheException con la propiedad ErrorCode definida como CacheItemVersionMismatch. El siguiente diagrama y ejemplo de código lo ilustran.

'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");

Modelo de concurrencia pesimista

En el modelo de concurrencia pesimista, el cliente bloquea explícitamente los objetos para realizar operaciones. El resto de operaciones que solicitan bloqueos se rechazan (el sistema no bloquea las solicitudes) hasta que se elimina el bloqueo. Si los objetos están bloqueados, se devuelve un controlador de bloqueo como parámetro de salida. Este controlador de bloqueo es necesario para desbloquear el objeto. En caso de que la aplicación cliente finalice antes de liberar un objeto bloqueado, se proporcionan tiempos de espera para liberar los bloqueos. Los objetos bloqueados nunca caducan, pero pueden caducar inmediatamente después del desbloqueo si se supera su fecha de caducidad. Para obtener más información sobre los métodos que se usan con el modelo de simultaneidad pesimista, vea Métodos de simultaneidad (Almacenamiento en caché de Windows Server AppFabric).

Nota

No se admiten transacciones que incluyan varias operaciones. La aplicación que usa la memoria caché es la responsable de determinar el orden de los bloqueos y, en su caso, de detectar interbloqueos.

Advertencia
De todos modos, los clientes de caché pueden sustituir los objetos bloqueados en la memoria caché con el método Put. Las aplicaciones con caché habilitado son responsables de usar PutAndUnlock de forma coherente para elementos que usan el modelo de concurrencia pesimista.

Vea también

Conceptos

Métodos de simultaneidad (Almacenamiento en caché de Windows Server AppFabric)
Diagrama de la arquitectura física de almacenamiento en caché de Windows Server AppFabric
Diagrama de la arquitectura lógica de almacenamiento en caché de Windows Server AppFabric
Desarrollo de un cliente de caché (Almacenamiento en caché de Windows Server AppFabric)

  2011-12-05