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
Se você estiver executando um ambiente do
WebSphere 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
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.