VENDAS: 1-800-867-1389

Modelo de simultaneidade (cache na função para cache do Azure)

Atualizado: julho de 2010

noteObservação
Para orientação sobre como escolher a oferta Azure Cache para seu aplicativo, consulte Qual oferta de cache do Azure é ideal para mim?.

A arquitetura de cache permite que qualquer cliente de cache acesse qualquer dado em cache se seu acesso à rede e seus parâmetros de configuração forem adequados. Isso gera um desafio de simultaneidade.

Para ajudar o aplicativo a lidar com problemas de simultaneidade, há suporte a modelos de simultaneidade otimistas e pessimistas.

No modelo de simultaneidade otimista, as atualizações de objetos em cache não aceitam bloqueios. Em vez disso, quando o cliente de cache recebe um objeto do cache, também obtém e armazena a versão atual do objeto. Quando uma atualização é necessária, o cliente de cache envia o novo valor do objeto juntamente com o objeto da versão armazenada. O sistema só atualiza o objeto se a versão enviada corresponde à versão atual do objeto no cache. Cada atualização de um objeto altera seu número de versão, o que impede que a atualização substitua as alterações feitas por outra pessoa.

O exemplo neste tópico ilustra como a simultaneidade otimista mantém a consistência dos dados.

Neste exemplo, dois clientes de cache (cacheClientA e cacheClientB) tentam atualizar o mesmo objeto em cache, tendo a mesma chave RadioInventory.

Tempo zero: ambos os clientes recuperam o mesmo objeto

No tempo zero (T0), ambos os clientes de cache instanciam uma classe DataCacheItem para capturar o objeto em cache que pretendem atualizar, juntamente com informações adicionais associadas a esse objeto em cache, como as informações de versão e marca. Isso é ilustrado no exemplo de código a seguir.

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

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

noteObservação
Embora esse exemplo obtenha as informações de versão usando o método GetCacheItem para recuperar o objeto DataCacheItem, também é possível usar o método Get para obter o objeto DataCacheItemVersion associado ao item de cache recuperado.

Tempo um: a primeira atualização é bem-sucedida

No tempo um (T1), o cacheClientA atualiza o objeto em cache RadioInventory com um novo valor. Quando cacheClientA executa o método Put, a versão associada ao item de cache RadioInventory é incrementada. Nesse momento, cacheClientB tem um item de cache desatualizado. Isso é ilustrado no exemplo a seguir.

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

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

Tempo dois: a segunda atualização falha

No tempo dois (T2), cacheClientB tenta atualizar o objeto em cache RadioInventory usando o que agora é um número de versão desatualizado. Para impedir que as alterações de cacheClientA sejam substituídas, a chamada por cacheClientB do método Put falha. O cliente de cache gera um objeto DataCacheException com a propriedade ErrorCode definida como CacheItemVersionMismatch. Isso é ilustrado no exemplo de código a seguir.

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

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

No modelo de simultaneidade pessimista, o cliente bloqueia objetos explicitamente para executar operações. Outras operações que solicitem bloqueios são rejeitadas (o sistema não bloqueia solicitações) até que os bloqueios sejam liberados. Quando um objeto é bloqueado, um identificador de bloqueio é retornado como um parâmetro de saída. O identificador de bloqueio é necessário para desbloquear o objeto. Caso o aplicativo cliente seja encerrado antes de liberar um objeto bloqueado, são fornecidos tempos limite para liberar os bloqueios. Objetos bloqueados nunca expiram, mas podem expirar imediatamente após o desbloqueio se tiverem excedido o tempo de expiração.

Para obter mais informações sobre os métodos usados no modelo de simultaneidade pessimista, consulte Métodos de simultaneidade.

noteObservação
Não há suporte a transações que abranjam mais de uma operação.

noteObservação
O aplicativo que usa o cache é responsável por determinar a ordem dos bloqueios e detectar eventuais deadlocks.

WarningAviso
Os objetos bloqueados no cache continuam passíveis de substituição por qualquer cliente de cache com o método Put. Os aplicativos habilitados para armazenamento em cache são responsáveis pelo uso consistente de PutAndUnlock para itens que usem o modelo de simultaneidade pessimista.

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft