Ben Wang
Bela Ban
Manik Surtani
Scott Marlow
Galder Zamarreño
Plataforma do Aplicativo JBoss
Enterprise 5.0
Perguntas Frequentes sobre o
JBoss Cache
para uso com a Plataforma do Aplicativo do JBoss Enterprise 5.0
Edição 2.0
Plataforma do Aplicativo JBoss Enterprise 5.0 Perguntas Frequentes
sobre o JBoss Cache
para uso com a Plataforma do Aplicativo do JBoss Enterprise 5.0
Edição 2.0
Ben Wang Bela Ban Manik Surtani Sco tt Marlo w Galder ZamarreñoCopyright © 2009 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners.
Resumo
. . . . . . . . . . . . . . . . . . . . . . . .
Índice
Capítulo 1. Informações GeraisCapítulo 2. JBoss Cache: Core Capítulo 3. Políticas de Remoção Capítulo 4 . Cache Loaders Capítulo 5. Troubleshooting Histórico de Revisão 3 5 13 14 17 18 Índice
P: R: P: R: P: R: P: R: P: R: P: R:
Capítulo 1. Informações Gerais
O que é o JBoss Cache?
O JBoss Cache é um cache replicado e transacional. Ele é replicado, uma vez que as instâncias do JBoss Cache múltiplas poderão ser distribuídas (tanto com o mesmo JVM ou através de diversos JVMs, se é que eles residem na mesma máquina ou em diferentes máquinas na rede), além dos dados serem replicados através de todo grupo. Isto é transacional uma vez que um usuário pode configurar um gerenciador de transação JTA compilante e fazer qualquer interação de cache transacional. Perceba que o cache pode também ser rodado sem qualquer replicação, sendo que este é o modo local.
O JBoss Cache aparece em duas versões: Core e POJO. A biblioteca core (usando a interface
org.jboss.cache.Cache) é a biblioteca adjacente que organiza os dados numa estrutura
como a do tree e manuseia todas as características de replicação, remoção, passivação e bloqueamento dos dados no cache. A biblioteca POJO (usando a interface
org.jboss.cache.pojo.PojoCache) está construída sob a biblioteca core e permite a
introspecção de objetos no cache fornecendo uma coerência transparente de uso do JBoss AOP. Perceba que a edição do POJO do JBoss Cache (normalmente referida como POJO Cache) vem com um conjunto separado de documentação (Guia dos Usuários, FAQ, etc.) disponível no documentation website.
Quem são os desenvolvedores do JBoss Cache?
O JBoss Cache possui uma comunidade ativa de desenvolvedores e contribuidores. O projeto foi fundado pela Bela Ban e é liderado por Manik Surtani. Jason Greene é o líder para o subsistema do POJO Cache e outros contribuidores, ambos antigos e atuais, incluem Ben Wang, Harald Gliebe, Brian Stansberry, Vladimir Blagojevic, Mircea Markus, Jimmy Wilson, Galder Zamarreño e Elias Ross.
Como é que eu posso saber em qual versão do JBoss Cache eu estou trabalhando?
O java -jar jbosscache-core.jar imprimirá detalhes da versão.
Eu posso rodar o JBoss Cache fora da Plataforma do Aplicativo JBoss Enterprise?
Certamente! Mesmo que o JBoss venha integrado com a Plataforma do Aplicativo JBoss
Enterprise, ele pode ser usado em qualquer outro servidor do Java EE, tal como o BEA WebLogic, IBM Websphere ou Tomcat. Além disso, ele pode rodar num processo Java autônomo,
completamente fora de um servidor do aplicativo. Consulte o Guia dos Usuários para maiores informações.
Como eu posso migrar meu aplicativo e configuração pelo uso do JBoss Cache 1.x para o 2.x?
Consulte this wiki page para maiores informações.
E a respeito do 2.x para o 3.x?
O JBoss Cache 3.x é um API compatível com o 2.x, mesmo que você refatore o seu código para não usar métodos desatualizados, uma vez que eles desaparecerão em liberações futuras do JBoss Cache.
O JBoss Cache 3.x vem com todo formato de nova configuração. Os arquivos de configuração 2.x antigos continuarão a funcionar, mesmo que você obtenha um aviso nos logs sobre isto.
Recomendamos a migração de seu arquivo de configuração ao seu novo formato. Os scripts são fornecidos com a distribuição do JBoss Cache 3.x para migrar os arquivos de configuração (consulte config2to3.sh e config2to3.bat).
Perceba que para aproveitar alguns dos novos recursos do JBoss Cache 3.x, você precisará usar o novo formato de configuração.
P: R: P: R: P: R: P: R: P: R: P: R:
Capítulo 2. JBoss Cache: Core
Posso rodar instâncias múltiplas do JBoss Cache no mesmo VM?
Sim. Existem alguns cenários onde você talvez queira rodar instâncias múltiplas do JBoss Cache. Por exemplo, você poderá rodar as instâncias múltiplas de um cache local, pelas quais cada instância possui sua própria configuração (por exemplo: diferente política de cache). Neste caso, você precisará de arquivos de configuração xml múltiplos.
O JBoss Cache pode rodar como um cache de segundo nível dentro do Hibernate?
Sim. Desde a versão 3.0 do Hibernate, você pode configurá-lo usando o JBoss Cache como um cache de segundo nível. Para maiores detalhes, consulte a documentação Hibernate e veja também o link: this wiki page.
O JBoss Cache 3.x com o MVCC funciona particularmente bem como um cache de segundo nível do Hibernate.
E a respeito do uso do POJO Cache como um cache Hibernate?
Não há a necessidade de usar o POJO Cache para um cache de segundo nível dentro do
Hibernate, uma vez que o Hibernate gerencia campos fine-grained em objetos Java. Desta forma, o uso do POJO Cache não trará nenhuma vantagem, e será um desempenho desnecessário.
Como eu posso configurar o JBoss Cache?
Você pode configurar o JBoss Cache através de um arquivo de configuração xml ou de forma programática usando um objeto org.jboss.cache.config.Configuration, passado à instância org.jboss.cache.CacheFactory.
Posso usar um esquema ou DTD para validar meu arquivos de configuração do JBoss Cache?
Sim, a partir do JBoss Cache 3.x, Um esquema XSD é fornecido em seu arquivo jbosscache-core.jar e está disponível online no http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd. Você pode configurar seu IDE, editor de texto ou ferramenta de preparação de multimídia para uso deste esquema para validar o seu arquivo.
Qual é a diferença entre os diferentes modos de cache?
O JBoss Cache possui cinco diferentes modos de cache, por exemplo: LOCAL, REPL_SYNC,
REPL_ASYNC, INVALIDAT ION_SYNC e INVALIDAT ION_ASYNC. Caso você queira rodar o JBoss
Cache como uma instância única, então você terá que configurar o modo do cache para LOCAL, de forma que isto não tente replicar coisa alguma. Caso você deseje ter replicações síncronas no meio de diferentes instâncias do JBoss Cache, você configurará isto para REPL_SYNC. Para a replicação síncrona, use AYSNC_REPL. Caso você não queira replicar os dados, mas simples informar os demais caches num cluster, do qual os dados sob endereços específicos são antigos e deverão ser removido da memória, utilize INVALIDATION_SYNC ou INVALIDTAION_ASYNC. Os comportamentos síncronos ou assíncronos são aplicados para a invalidação assim como a replicação.
Perceba que o ASYNC_REPL e INVALIDATION_ASYNC não são bloqueados. Isto pode ser usado Capítulo 2. JBoss Cache: Core
P: R: P: R: P: R: P: R: P: R:
quando você desejar possuir outro JBoss Cache servindo como um espelho ou back up, além de você não querer esperar pela confirmação que este espelho recebeu suas mensagens.
Como o mecanismo da replicação do JBoss Cache funciona?
O JBoss Cache alcança JGroups para comunicações da rede. Uma seção de configuração do JGroups está presente em sua configuração do JBoss Cache.
O usuário pode configurar o cluster de instâncias do JBoss Cache apenas dividindo o mesmo nome de cluster (cluster name). Há também a opção de se preencher os dados do cache ou não, até o período de instalação da nova instância no atributo ClusterConfig.
Perceba que em algum momento todas as instâncias juntam-se ao mesmo grupo de replicação, e que cada mudança de replicação é propagada para todos os membros participantes. Não há nenhum mecanismo para sub-particionamento onde algumas replicações podem ser feitas com apenas um sub-conjunto de membros, a não ser que você esteja usando a Replicação Buddy. Isto pertence a nossa lista de tarefas a serem feitas.
Eu estou rodando um cluster de nó 2. Os caches continuarão a rodar, no caso da rede cair?
Sim, ambos continuarão a rodar, mas dependendo do ser modo de replicação, todas as transações ou operações não serão completadas. Caso o REPL_SYNC seja utilizado, as
operações falharão enquanto que o REPL_ASYNC é usado, elas irão sobreviver. Mesmo que elas sejam bem sucedidas, os caches estarão fora do sync.
Eu posso clicar na biblioteca X ao invés do JGroups para manusear as chamadas remotas e os grupos de comunicações?
Neste caso a resposta é não. Nós possuimos uma camada de abstração entre a suíte de comunicação e o JBoss Cache e as tubulações, e isto poderá aparecer como um recurso em qualquer estado futuro.
O cache precisa realizar a replicação para todas as demais instâncias no cluster? Isto não será muito lento, caso o cluster seja grande?
A replicação não precisa ocorrer para cada nó no cluster. Este recurso - chamado Replicação Buddy - permite que cada nó escolha um ou mais 'buddies' no cluster, e apenas realiza a replicação para os próprios buddies. Isto permite que um cluster realize uma escala com facilidade, sem nenhum impacto na memória ou no tráfico de rede de cada nó adicionado. Consulte o Guia do Usuário para maiores informações sobre a Replicação Buddy e como isto pode ser usada para atingir um alto nível de escabilidade.
Eu estou usando a Replicação Buddy. Eu irei precisar de algum tipo de afinidade de sessão?
A afinidade de sessão relaciona o retorno à mesma instância de cache para os mesmos dados sendo usado. Enquanto isto é uma restrição e não uma solicitação para a Replicação Buddy, recomendamos minimizar o estado em movimento sobre o cluster.
P: R: P: R: P: R: P: R: P: R: P: R: P: R: P:
Caso eu tenha a necessidade de possuir diferentes propriedades de configuração (ex.: CacheMode e IsolationLevel), eu precisarei criar instâncias
org.jboss.cache.Cache com a configuração apropriada?
Sim. Todas as propriedades mencionadas acima são por instância de cache. Portanto, você precisará instâncias do org.jboss.cache.Cache.
Isto não é caro para o ponto de vista de uma rede, ex.: necessidade de criar soquetes para cada instância org.jboss.cache.Cache?
Sim. Para tais casos, recomenda-se que você configure seu cache usando o JGroups Multiplexer, que permite diversos caches para compartilhar um único canal do JGroups. Por favor consulte o Guia dos Usuários para maiores detalhes de como configurar o JGroups Multiplexer.
Um procedimento mais rápido e eficaz é o uso de um transporte compartilhado no JGroups. Por favor consulte the JGroups documentation para maiores informações de como realizar isto.
O elemento de configuração ClusterName possui qualquer relação com o JBoss AS cluster PartitionName?
Sim. Existem ambos os nomes do grupo JGroups. Fora a noção de um canal no JGroups, isto pode também dividir o canal em nomes de grupos diferentes.
Quando utilizando os componentes múltiplos baseados no JGroups [cluster-service.xml, cache (instâncias múltiplas)], qual é a maneira correta/válida para configurar aqueles componentes, certificando-se de que meus endereços multicast não sofrerão conflitos?
Existem dois parâmetros a serem considerados: endereços multicast (mais o porto) e o nome do grupo. No mínimo, você terá que rodar os componentes usando um nome de grupo diferente. Porém, a opção de rodá-los no mesmo canal ou não, dependerá se o desempenho de
comunicação estiver crítico para você ou não. Caso, isto seja, então seria melhor rodá-los em diferentes canais.
O JBoss Cache suporta atualmente o armazenamento de persistência do cache?
Sim. O JBoss Cache possui a interface cache loader, da qual suporta a persistência do cache. Veja a seguir mais informações a este respeito.
O JBoss Cache suporta atualmente a passivação/overflow do cache para o armazenamento de dados?
Sim. O JBoss Cache usa o cache loader para suportar a passivação/overflow do cache. Consulte a documentação em como configurar e usar este recurso.
O segmento do JBoss Cache é seguro?
Sim, ele é um segmento seguro.
O JBoss Cache suporta as transações XA (2PC) agora?
R: P: R: P: R: P: R: P: R:
Não, mesmo que isto esteja também na nossa lista de tarefas. Nossa implementação interna usa um procedimento similar 2PC para coordenar uma transação entre instâncias diferentes, porém o JBoss Cache não é um recurso XA.
Quais dos gerenciadores de transação são suportadas pelo JBoss Cache?
O JBoss Cache suporta qualquer TransactionManager que é compatível com o JTA, tal como JBoss Transactions.
Enquanto o JBoss Cache não lança o gerenciador de transação dummy
(org.jboss.cache.transaction.DummyTransactionManager), não recomendamos o uso disto para produção. Ele não é um segmento seguro e é destinado para testes internos apenas.
Como é que eu posso configurar o cache para ser transacional?
Você tanto usará o gerenciador de transação padrão que lança o JBoss AS ou você terá que implementar a interface org.jboss.cache.transaction.TransactionManagerLookup e retornar a uma instância de sua implementação javax.transaction.TransactionManager. O TransactionManagerLookupClass de propriedade de configuração define a classe a ser usada pelo cache para busca de uma referência a um gerenciador de transação. É fundamental a implementação desta interface para suporte de outros gerenciadores de transação. O cache buscará pelo contexto de transação a partir deste gerenciador de transação, uma vez que este atributo seja especificado.
A classe org.jboss.cache.transaction.GenericTransactionManagerLookup que lança o JBoss Cache está apta a detectar e realizar o bind aos gerenciadores de transação mais populares. Consulte os GenericTransactionManagerLookup Javadocs para maiores informações.
Como eu posso controlar o nível de bloqueamento do cache?
O JBoss Cache permite você controlar o nível de bloqueamento do cache através do nível de isolação de transação. Isto é configurado através do atributo IsolationLevel. Os Níveis de isolação de transação a partir do bloqueamento pessimista correspondem aos níveis de isolação, nomeadamente, NONE, READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ e
SERIALIZABLE. Perceba que estes níveis de isolação são ignorados, caso o bloqueamento
otimista for utilizado. Para maiores detalhes, por favor refira-se ao manual do usuário.
A partir do JBoss Cache 3.x, quando utilizando o esquema de bloqueamento MVCC, apenas o
READ_COMMIT T ED e REPEAT ABLE_READ, serão suportados. Qualquer outro nível de isolação
fornecida, será tanto atualizado ou reduzido em acordo.
Como o JBoss Cache bloqueia os dados para o acesso atual?
No JBoss Cache 2.x, o bloqueamento pessimista é usado para bloquear os nós dos dados, baseando-se no nível configurado de isolação, por padrão. Nós também oferecemos o
bloqueamento otimista para permitir uma boa concordância ao custo do pequeno processamento elevado e desempenho. Consulte a documentação para um melhor esclarecimento na
P: R: P: R: P: R: P: R: P: R: P: R:
MVCC (controle de concordância de versão múltipla), que é muito mais eficiente que o
bloqueamento otimista e pessimista. Para uma discussão detalhada de nossa implementação MVCC, consulte this blog entry e this wiki page.
Como eu ativo o Bloqueamento Otimista ou MVCC no JBoss Cache?
Por favor consulte a seção de configuração do Guia dos Usuários para maiores detalhes.
Eu posso usar o nível de bloqueamento do cache sem um contexto de transação?
Sim. O JBoss Cache controla o nó individual de comportamento de bloqueamento através das semânticas de nível de isolação. Isto significa que mesmo que você não utilize uma transação, você poderá especificar o nível de bloqueamento através do nível de isolação. Você poderá pensar no comportamento de bloqueamento do nó fora da transação, como se isto estivesse sob a transação com o auto_commit conectado.
O JBoss Cache suporta as semânticas SELECT FOR UPDATE?
Sim, mas isto é apenas possível caso você esteja rodando com uma transação JTA e estiver usando tanto MVCC ou PESSIMISTIC como seu esquema de bloqueamento do nó.
Realize o seguinte para atingir as semânticas SELECT FOR UPDATE:
// start transaction ...
cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true); Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node ...
...
// end transaction
Qual é a frequência das mensagens do cache broadcast sobre a rede com a replicação (REPL_SYNC/REPL_ASYNC) ou invalidação
(INVALIDATION_SYNC/INVALIDATION_ASYNC)?
Caso as atualizações estejam sob a transação, os broadcasts acontecerão apenas quando a transação estiver para ser confirmada (na realidade, durante o estágio de preparação interno). Isto é, ela será uma atualização em lote. No entanto, caso as operações não estejam sob o contexto da transação, cada atualização efetuar o trigger na replicação. Perceba que, isto implica no desempenho caso a latência da rede for o problema.
Como eu posso realizar uma remoção em massa?
Caso você realize um cache.removeNode("/myroot"), ele removerá de maneira repetitiva todas as entradas sob "/myroot".
Eu posso monitorar e gerenciar o JBoss Cache?
Sim, usando o console JMX tal como o lançado com o JBoss AS ou utilidade jconsole do JDK 5. Capítulo 2. JBoss Cache: Core
P: R: P: R: P: R: P: R: P: R:
Verifique o capítulo de título Informação de Gerenciamento no Guia do Usuário do JBoss Cache, para maiores informações.
O JBoss Cache usa uma característica ":" em seu nome de objeto. Isto causa problemas com o servidor MBean. O que eu posso fazer a respeito?
Isto é algo que nós vimos com os servidores MBean. Por padrão, o JBoss Cache usa
jboss.cache:service=JBossCache como um prefixo a todos os objetos em que realiza o
bind no JMX. Use o parâmetro JMX -Djbosscache.jmx.prefix para passar um prefixo alternativo.
Eu posso desativar os atributos do gerenciador do JBoss Cache?
Sim, você pode. Consulte a seção no Guia dos Usuários do JBoss Cache.
O que aconteceu com o jboss-serialization.jar?
A partir do JBoss Cache 2.0.0, a dependência da Serialização do JBoss foi retirada, uma vez que a maior vantagem da Serialização do JBoss está disponível no Java 5 VMs atualizado. Uma vez que o JBoss Cache 2.0.0 possui linha baseada no Java 5, não houve necessidade de fornecer estes benefícios separadamente.
O JBoss Cache suporta o particionamento?
Não, ele não suporta isto agora. O JBoss Cache não suporta o particionamento que um usuário pode configurar para ter diferentes conjunto de dados residindo em diferentes instâncias, enquanto participando como um grupo de replicação.
O JBoss Cache pode manusear o conceito do carregamento de classe do aplicativo interno, por exemplo: um container Java EE?
O carregamento de classe do aplicativo específico é usado abertamente dentro de um container Java EE. Por exemplo: o aplicativo da web pode solicitar um novo carregador de classe para o escopo numa versão específica da biblioteca do usuário. No entanto, pelo padrão o JBoss Cache é agnóstico ao classloader. Em geral, isto leva a dois tipos de problemas:
A instância do objeto é armazenada no cache1 e replicada ao cache2. Como resultado, a instância no cache2 é criada pelo carregador de classe do sistema. A replicação poderá falhar, caso o carregador de classe do sistema no cache2 não possua acesso à classe solicitada. Mesmo que a replicação não falhe, um segmento do usuário no cache2 poderá não ter acesso ao objeto, caso o segmento do usuário esteja esperando por um tipo definido do carregador de classe do aplicativo.
A instância do objeto é criada pelo segmento 1 e será acessada pelo segmento 2 (com dois carregadores de classloaders). O Jboss Cache não possui noção dos diferentes
carregadores de classe envolvidos. Como resultado, você terá um ClassCastException. Este é um problema padrão na passagem de um objeto, a partir de um espaço do aplicativo para outro. O JBoss Cache apenas adiciona um nível de indireções na passagem do objeto. Para resolver o primeiro tipo de problema, o JBoss Cache usa um .CacheMarshaller.
P: R: P: R: P: R:
CacheMarshaller do guia do usuário, para maiores informações.
Para resolver o segundo problema, você poderá usar a opção de configuração
UseLazyDeserialization no JBoss Cache, que empacota seus objetos num pacote
Marshalledvalue. O MarshalledValue serializa e deserializa seu objeto a pedido, garantido
o apropriado carregador de classe de contexto local seja usado de cada vez.
O JBoss Cache suporta atualmente a notificação de pré e pós-evento?
Sim. Um boolean é passado à cada chamada de retorno de notificação identificando se é que a chamada de retorno é antes ou depois do evento. Consulte a anotação
org.jboss.cache.notifications.annotations.CacheListener para maiores
detalhes.
Como eu implemento um ouvinte personalizado para escutar os eventos do cache?
Consulte o Guia dos Usuários sobre este assunto.
Posso usar o atributo UseRegionBasedMarshalling no JBoss Cache com a finalidade das ClassCastExceptions ocorrerem, quando acessando os dados em cada cache, do qual acabou de ser re-implementado?
Sim, você pode. Originalmente o cache Marshalling foi criado como um trabalho para aqueles caches replicados sendo que o estado de transferência não teve acesso aos classloaders definindo os objetos no cache.
Em cada implementação, o JBoss cria um novo carregador de classe por artefato de
implementação de nível top, por exemplo um EAR. Você terá que ter em mente que a classe no servidor do aplicativo é definido não apenas pelo nome da classe, mas também por seu
carregador de classe. Desta forma, assumimos que o cache não é implementado como parte de sua implementação. Você poderá implementar um aplicativo e colocar instâncias de classes pertencentes a esta implementação dentro do cache. Caso você tenha feito a re-implementação e tentar realizar a obtenção da operação dos dados adicionados anteriormente, isto poderá resultar numa ClassCastException. Isto deve-se ao fato de que mesmo que os nomes das classes serem os mesmos, as definições de classes não são as mesmas. O carregador de classe atual é diferente ao daquele em que as classes foram originalmente aderidas.
Pela ativação do marshalling, você poderá controlar o ciclo de vida dos dados no cache e no caso de uma desimplementação, você desativará a região e des-registrará o classloader que você registraria na implementação e removeria os dados localmente no cache. Isto significa que na próxima implementação, os dados não estarão no cache, portanto evitando o problema. É claro que o uso do marshalling para contornar este problema, é apenas recomendado quando você possuir algum tipo de persistência retornando para onde os dados sobrevivem, por exemplo o uso dos carregadores de CacheLoaders, ou quando o JbossCache for usado como cache de segundo nível num framework de persistência.
Para implementação deste recurso, por favor siga as instruções indicadas no exemplo encontrado na seção CacheMarshaller do guia do usuário. É importante perceber que ao invés de um
ServletContextListener, você poderá adicionar este código ao MBean, que contém os
métodos de ciclo de vida, como por exemplo: start() e stop(). A chave para este MBean dependerá no cache alvo, de forma que ele pode operar contanto que o cache esteja funcionando e rodando.
P: R: P: R: P: R: P: R:
Capítulo 3. Políticas de Remoção
O JBoss Cache suporta as políticas de remoção?
Sim. O JBoss Cache normalmente suporta políticas de remoção múltiplas, tais como LRU, MRU e FIFO. Os usuários podem conectar seus próprios algorítimos de política de remoção. Consulte o Guia do Usuário do JBoss Cache para maiores detalhes.
A política de remoção do JBoss Cache opera no modo de replicação?
Sim e não.
A política de remoção apenas opera no modo local. Isto é, os nós são apenas removidos localmente. O resultado poderá levar os conteúdos do cache a não estarem sincronizados
temporariamente. Mas, quando um usuário tentar obter os conteúdos do cache de um nó removido e descobrir que ele é nulo (por exemplo: o get retornar nulo), ele deverá obter isto a partir de outra fonte de recurso e re-abastecer os dados no cache. Neste momento, o conteúdo do nó será propagado e o conteúdo do cache estará em sync.
No entanto, você pode continuar rodando as políticas de remoção com a configuração de modo do cache, para tanto o REPL_SYNC ou REPL_ASYNC. Dependo do seu caso de uso, você poderá configurar instâncias de cache múltiplas para ter a própria política de remoção (da qual é aplicada localmente) ou apenas possui instâncias selecionadas com as políticas de remoção ativadas. Um nó removido localmente pode também ser persistido ao armazenamento backend e um usuário poderá restaurar isto, a partir do armazenamento mais tarde, com a opção do cache loader.
O JBoss Cache suporta Region?
Sim. O JBoss Cache possui a noção de região, onde um usuário pode configurar os parâmetros da política de remoção (por exemplo: maxNodes ou timeToIdleSeconds).
Uma região no JBoss Cache marca uma porção da hierarquia do tree, por exemplo: um nome inteiramente qualificado (org.jboss.cache.Fqn). Por exemplo: um usuário poderá definir
/org/jboss e /org/foocom como duas regiões separadas. No entanto, perceba que você
poderá configurar a região de maneira programática agora, por exemplo: tudo deve ser configurado através do arquivo xml.
Eu acionei a política de remoção, por que eu continuo obtendo a exceção (OOM) "falta de espaço na memória"?
O OOM pode ocorrer quando a velocidade de acesso do cache excede a velocidade do
cronômetro de manuseio da política de remoção. O manuseador da política de remoção estimulará cada segundo do wakeUpIntervalInSeconds (ou wakeUpIntervalSeconds segundos, antes do 3.x) para processar a fila do evento de remoção. Desta maneira, quando a fila estiver cheia, ela criará um backlog e levará às exceções sem espaço de memória, a não ser que o cronômetro da remoção o alcance. Para endereçar este problema, adicionado ao aumento do tamanho de empilhamento VM, você poderá também reduzir o wakeUpIntervaleInSeconds, de forma que o segmento processe a fila mais frequente.
P: R:
P: R:
Capítulo 4. Cache Loaders
O que é o cache loader?
O cache loader é a conexão do JBoss Cache a um armazenamento de dados (persistentes). O cache loader é chamado pelo JBoss Cache para produzir dados a partir de um armazenamento, quando os mesmos dados não estiverem no cache, e quando as modificações efetuadas aos dados do Cache Loader forem chamadas para armazenar aquelas modificações de volta ao armazenamento.
Em conjunção às políticas de remoção, o JBoss Cache com o cache loader permitem que o usuário mantenha um cache vinculado para um grande armazenamento de dados backend. Os dados usados são frequentemente produzidos a partir de um armazenamento de dados dentro do cache, e os dados menos utilizados são removidos. Tudo isto, com o objetivo de fornecer o
acesso rápido aos dados acessados com mais frequência. Isto é completamente configurado através do XML e o programador não precisa preocupar-se com o carregamento e a remoção. O JBoss Cache atualmente lança diversas implementações do cache loader, incluindo:
org.jboss.cache.loader.FileCacheLoader: isto implementa o uso do sistema do
arquivo para o armazenamento e restauração de dados. Os nós do JBoss Cache estão mapeados para diretórios e sub-nós para sub-diretórios, etc. Os atributos de um nó estão mapeados para um arquivo de data, dentro do diretório.
org.jboss.cache.loader.jdbm .Jdbm CacheLoader: esta implementação baseia-se no
JDBM, um engenho persistente transacional baseado em arquivo.
org.jboss.cache.loader.bdbje.BdbjeCacheLoader: esta implementação baseia-se
no banco de dados de Edição Berkeley DB Java do Oracle, um banco de dados transacional rápido e eficiente. Isto utiliza um arquivo único para o armazenamento completo. Perceba que se você usar o Berkeley DB cache loader com o JBoss Cache e desejar lançar seu produto, você terá que adquirir uma commercial license from Oracle.
org.jboss.cache.loader.JDBCCacheLoader: esta implementação usa o banco de
dados relacional como um armazenamento persistente.
Por favor, consulte a documentação do cache loaders do Guia do Usuário para maiores detalhes e informações.
O FileCacheLoader é recomendado para uso de produção?
Não, ele não é. O FileCacheLoader possui limitações severas de como restringir seu uso num ambiente de produção ou, caso usado em tal ambiente, ele deverá ser usado com cuidado e total entendimento destas limitações.
Ele é ineficiente para trees mais profundos devido à maneira com que o FileCacheLoader representa a estrutura do tree no disco (diretórios e arquivos) transversal.
O uso em sistemas de arquivo compartilhados como o NFS, compartilhamentos do Windows, etc, devem ser evitados uma vez que eles não implementam o próprio bloqueamento do arquivo e podem causar corrupção de dados.
O uso com um nível isolação de NONE pode causar gravações com corrupção uma vez que as segmentações tentam gravar o mesmo arquivo.
Os sistemas de arquivo não são transacionais por herança, portanto quando tentando usar o seu cache num contexto transacional, as falhas da gravação do arquivo (o que acontece durante a fase de confirmação) não poderão ser recuperadas.
P: R: P: R: P: R: P: R: P: R: P: R: P: R: P:
estressante, transacional ou de alta concordância, além de seu uso ser registro para testes.
Eu posso gravar o CacheLoaders como assíncrono?
Sim. Configure o atributo async para verdadeiro. Consulte a documentação do Guia do JBoss Cache para informações mais detalhadas. Pelo padrão, todos as gravações do cache loader são assíncronas e irão bloquear.
Eu posso gravar meu próprio cache loader?
Sim. O cache loader é uma classe implementando o
org.jboss.cache.loader.CacheLoader ou
org.jboss.cache.loader.AbstractCacheLoader estendido. Ele é configurado através do
arquivo XML (consulte o Guia JBoss Cache e a documentação tutorial).
O cache loader precisa utilizar um armazenamento persistente?
Não, um cache loader poderia produzir (e possivelmente armazenar), por exemplo, os próprios dados a partir de um webdav-capable webserver. Outro exemplo, é o servidor caching proxy, pelo qual produz os conteúdos a partir da web. Perceba que uma implementação do CacheLoader não poderá implementar a funcionalidade de 'armazenamento' neste caso, mas apenas a
funcionalidade de 'carregamento'.
Eu preciso pagar para usar o Berkeley DB CacheLoader do Oracle?
Não, mas apenas se você utilizá-lo para uso pessoal. Logo após a distribuição de seu produto com o BdbjeCacheLoader, você terá que comprar uma licença comercial a partir do Oracle.
Existe alguma ferramenta disponível para monitoras a instância Berkeley DB?
Sim. O Oracle lança uma ferramenta de monitoração baseada no JMX, chamada JEMonitor, que pode ser baixada a partir do website do Oracle.
Quando ajustando minha instância Berkeley DB, onde devo colocar meu arquivo je.properties?
O je.properties deverá residir no seu diretório principal Berkeley DB. Este é o diretório pelo qual você passa a propriedade da configuração location do BDBJECacheLoader.
Posso usar mais de um cache loader?
Sim. Você pode agora descrever diversos cache loaders (consulte a seção de de cache loaders no manual do usuário) com o novo elemento do CacheLoaderConfiguration XML. O impacto é que o cache observará todos os armazenamentos do cache na ordem em que eles foram
configurados, até que isto encontre um elemento válido e não-nulo de dados. Todos os cache loaders são gravados (a não que o elemento ignoreModifications tenha sido configurado para verdadeiro num carregador de cache específico).
Posso migrar um JDBCacheLoader ou FileCacheLoader baseado no armazenamento do cache, contendo dados formatados com o JBoss Cache 1.x.x para o formato do
R:
P: R:
JBoss Cache 2.0?
Sim. Consulte a seção "Transformação dos Cache Loaders" juntamente com a seção "Cache Loaders" localizada no Guia dos Usuários do JBoss Cache.
O TCPDelegatingCacheLoader está resiliente com a inicialização doTCPCacheServer?
A partir do JBoss Cache 2.1.0, a resposta é sim. Consulte o Guia dos Usuários para maiores detalhes de como configurar e ajustar suas tentativas e período de espera para restabelecimento da conexão TPC.
Antes disso, a reinicialização do TCPCacheServer significará também a reinicialização de seu aplicativo que usa o cache.
P: R:
Capítulo 5. Troubleshooting
Eu estou enfrentando dificuldades em inicializar o JBoss Cache. Onde eu posso obter informações a respeito do troubleshooting?
A seção de Troubleshooting pode ser encontrada no seguinte link: wiki link.
Histórico de Revisão
Revisão 2.0-4 .4 02 Fri Oct 25 2013 Rüdiger Landmann
Rebuild with Publican 4.0.0
Revisão 2.0-4 .1 2013-06-11 Misty Stanley-Jones
Rebuild for updated legal template
Revisão 2.0-4 2012-07-18 Anthony Towns
Rebuild for Publican 3.0
Revisão 1.0-0 Wed Oct 21 2009 Laura Bailey
