O WebSphere eXtreme Scale inclui plug-ins de cache de nível 2 (L2) para ambos os provedores OpenJPA e Hibernate Java Persistence API (JPA). Quando você usar um desses plug-ins, seu aplicativo usará a API do JPA. Uma grade de dados é introduzida entre o aplicativo e o banco de dados, melhorando os tempos de resposta.
Usar o eXtreme Scale como um provedor de cache L2 aumenta o desempenho na leitura e consulta de dados e reduz a carga para o banco de dados. O WebSphere eXtreme Scale tem vantagens sobre as implementações de cache integradas porque o cache é automaticamente replicado entre todos os processos. Quando um cliente armazena em cache um valor, todos os outros clientes conseguem usar o valor armazenado em cache que está localmente na memória.
É possível configurar a topologia e as propriedades para o provedor de cache L2 no arquivo persistence.xml. Para obter mais informações sobre como configurar essas propriedades, consulte Propriedades de Configuração do Cache JPA.
Quando ativadas, as operações de consulta usam o cache de consulta de JPA. Ative o cache de consulta de JPA somente para aplicativos com altas proporções de leitura para gravação, por exemplo quando você está se aproximando de 99% de operações de leitura. Se você usar o cache de consulta de JPA, deverá usar o Topologia Integrada ou Topologia Intradomínio.
A operação de localização por chave busca uma entidade de destino se a entidade de destino não tem nenhum relacionamento. Se a entidade de destino tiver relacionamentos com o tipo de busca EAGER, esses relacionamentos serão buscados juntamente com a entidade de destino. No cache de dados de JPA, a busca desses relacionamentos faz com que alguns acertos do cache obtam todos os dados de relacionamento.
Em um sistema com algumas JVMs, existe latência de replicação de dados para operações de gravação. O objetivo do cache é manter uma visualização de dados sincronizados final entre todas as JVMs. Quando você estiver usando a topologia intradomínio, existirá um atraso de replicação de dados para operações de gravação. Aplicativos que usam essa topologia devem ser capazes de tolerar leituras antigas e gravações simultâneas que podem sobrescrever os dados.
Com uma topologia intradomínio, os shards primários são posicionados em cada servidor de contêiner na topologia. Esses shards primários contêm o conjunto completo de dados para a partição. Qualquer um desses shards primários também podem concluir as operações de gravação em cache. Essa configuração elimina o gargalo na topologia integrada na qual todas as operações de gravação de cache deve passar por um shard primário único.
Em uma topologia intradomínio, nenhum shard de réplica é criado, mesmo se as réplicas tiverem sido definidas em seus arquivos de configuração. Cada shard primário redundante contém uma cópia completa dos dados, de modo que cada shard primário também pode ser considerado como um shard de réplica. Essa configuração usa uma única partição, semelhante à topologia integrada.
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING
Vantagens:
Limitações:
Uma topologia integrada cria um servidor de contêiner dentro do espaço do processo de cada aplicativo. O OpenJPA e o Hibernate lêem a cópia na memória do cache diretamente e gravam para todas as outras cópias. É possível melhorar o desempenho de gravação usando replicação assíncrona. Esta topologia padrão executa melhor quando a quantidade de dados armazenados em cache é pequena o suficiente para ajustar-se a um único processo. Com uma topologia integrada, crie uma única partição para os dados.
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=num_replicas,ReplicaMode=SYNC | ASYNC | NONE
Quando os dados em cache são muito grandes para se ajustarem em um único processo, é possível usar a topologia particionada integrada. Esta topologia divide os dados sobre diversos processos. Os dados são divididos entre os shards primários, portanto, cada shard primário contém um subconjunto dos dados. Ainda é possível usar esta opção quando a latência do banco de dados é alta.
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=num_partitions,ReplicaReadEnabled=TRUE | FALSE
Vantagens:
Limitação:
Por exemplo, para armazenar em cache 10 GB de dados com um máximo de 1 GB por JVM, 10 Java Virtual Machines são necessários. Portanto, o número de partições deve ser configurado para 10 ou mais. De maneira ideal, o número de partições deve ser configurado com um número primo no qual cada shard armazena uma quantidade razoável de memória. Geralmente, a configuração de numberOfPartitions é igual ao número de Java Virtual Machines. Com esta configuração, cada JVM armazena uma partição. Se você ativar replicação, será necessário aumentar o número de Java Virtual Machines no sistema. Caso contrário, cada JVM também armazenará uma partição de réplica, que consome tanta memória quanto uma partição primária.
Leia sobre oDimensionamento de Memória e Cálculo de Contagem de Partições para aumentar o desempenho de sua configuração escolhida.
Por exemplo, em um sistema com quatro Java Virtual Machines e com o valor da configuração de numberOfPartitions de 4, cada JVM hospeda uma partição primária. Uma operação de leitura tem 25% mais chance de buscar dados de uma partição disponível localmente, o que é muito mais rápido comparado ao obter dados de uma JVM remota. Se uma operação de leitura, como a execução de uma consulta, precisar buscar uma coleta de dados que envolva 4 partições igualmente, 75% das chamadas são remotas e 25% das chamadas são locais. Se a configuração de ReplicaMode for definida para SYNC ou ASYNC e a configuração de ReplicaReadEnabled for definida para true, as quatro partições de réplica são criadas e espalhadas pelos quatro Java Virtual Machines. Cada JVM hospeda uma partição primária e uma partição de réplica. A chance de que a operação de leitura execute localmente aumenta em 50%. A operação de leitura que busca uma coleta de dados que envolve quatro partições igualmente tem somente 50% de chamadas remotas e 50% de chamadas locais. Chamadas locais são muito mais rápidas do que chamadas remotas. Sempre que ocorrem chamada remotas, o desempenho cai.
Uma topologia remota armazena todos os dados armazenados em cache em um ou mais processos separados, reduzindo o uso da memória dos processos do aplicativo. É possível obter vantagem da distribuição de dados em processos separados ao implementar uma grade de dados replicada e particionada do eXtreme Scale. Ao contrário das configurações integradas e particionadas integradas descritas nas seções anteriores, se desejar gerenciar a grade de dados remota, você deverá fazer isso independente do aplicativo e do provedor JPA.
ObjectGridName=objectgrid_name,ObjectGridType=REMOTE
O tipo de ObjectGrid REMOTE não requer nenhuma configuração de propriedade porque a política de ObjectGrid e de implementação é definida separadamente a partir do aplicativo JPA. O plug-in do cache JPA conecta-se remotamente a um ObjectGrid remoto existente.
Como toda a interação com o ObjectGrid é remota, essa topologia possui o menor desempenho entre todos os tipos de ObjectGrid.
Vantagens:
Limitação: