Cache Local Replicado pelo Peer

Você deverá assegurar-se de que o cache esteja sincronizado se vários processos com instâncias de cache independentes existirem. Para assegurar-se de que as instâncias de cache estejam sincronizadas, ative um cache replicado por peer com o Java Message Service (JMS).

WebSphere eXtreme Scale inclui dois plug-ins que propagam automaticamente mudanças de transação entre instâncias do ObjectGrid peer. O plug-in JMSObjectGridEventListener propaga automaticamente as mudanças do eXtreme Scale usando JMS.
Figura 1. Cache Replicado pelo Peer com Alterações que são Propagadas com JMS
O JMS propaga alterações entre duas instâncias do ObjectGrid que estão em execução em diferentes Java Virtual Machines. Cada instância do ObjectGrid está associada a um aplicativo.
Se você estiver executando um ambiente doWebSphere Application Server, o plug-in TranPropListener também estará disponível. O plug-in TranPropListener usa o gerenciador de alta disponibilidade (HA) para propagar as mudanças em cada instância do cache de peer.
Figura 2. Cache Replicado pelo Peer com Alterações que são Propagadas com o Gerenciador de Alta Disponibilidade
O gerenciador de HA propaga alterações entre duas instâncias do ObjectGrid que estão em execução em diferentes Java Virtual Machines. Cada instância do ObjectGrid está associada a um aplicativo.

Vantagens

  • Os dados são mais válidos porque os dados são atualizados mais frequentemente.
  • Com o plug-in TranPropListener, como no ambiente local, o eXtreme Scale pode ser criado programaticamente ou declarativamente com o arquivo XML descritor de implementação do eXtreme Scale ou com outras estruturas como Spring. A integração com o gerenciador de alta disponibilidade é feita automaticamente.
  • Cada BackingMap pode ser independentemente ajustado para melhor utilização da memória e concorrência.
  • As atualizações BackingMap podem ser agrupadas em uma única unidade de trabalho e podem ser integradas como um último participante nas transações de duas fases como transações JTA (Java Transaction Architecture).
  • Ideal para poucas topologias JVM com um conjunto de dados razoavelmente pequeno ou para armazenamento em cache de dados frequentemente acessados.
  • As atualizações em cada eXtreme Scale são replicadas para todas as instâncias do eXtreme Scale do peer. As alterações são consistentes desde que uma assinatura durável seja utilizada.

Desvantagens

  • A configuração e a manutenção para o JMSObjectGridEventListener podem ser complexas. O eXtreme Scale pode ser criado programaticamente ou declarativamente com o arquivo XML descritor de implementação do eXtreme Scale ou com outras estruturas tais como Spring.
  • Não escalável: A quantidade de memória necessária para que o banco de dados possa dominar a JVM.
  • Funciona inadequadamente ao incluir Java Virtual Machines:
    • Os dados não podem ser facilmente particionados
    • A invalidação é custosa.
    • Cada cache deve ser aquecido de maneira independente

Quando Utilizar

Use a topologia de implementação apenas quando a quantia de dados a ser armazenada em cache for pequena, podendo ajustar-se a uma única JVM e se for relativamente estável.