Contêineres de EJB

Um contêiner Enterprise JavaBeans (EJB) fornece um ambiente de tempo de execução para enterprise beans no servidor de aplicativos. O contêiner cuida de todos os aspectos da operação de um enterprise bean dentro do servidor de aplicativos e atua como um intermediário entre a lógica de negócio criada pelo usuário dentro do bean e o resto do ambiente do servidor de aplicativos.

Um ou mais módulos EJB, cada um contendo um ou mais enterprise beans, podem ser instalados em um único contêiner.

O contêiner de EJB fornece muitos serviços ao enterprise bean, incluindo os seguintes:
  • Iniciar, confirmar e efetuar rollback de transações, conforme necessário.
  • Manter conjuntos de instâncias de enterprise beans prontos para pedidos de entrada e mover essas instâncias entre os conjuntos inativos e um estado ativo, assegurando que as condições de encadeamento dentro do bean sejam satisfeitas.
  • Mais importante, sincronizar automaticamente os dados nas variáveis de uma instância de enterprise bean com os itens de dados correspondentes armazenados em armazenamento persistente.

Por manter dinamicamente um conjunto de instâncias de beans ativos e sincronizar o estado do bean com o armazenamento persistente quando os beans são movidos para e de um estado ativo, o contêiner torna possível para um aplicativo gerenciar muito mais instâncias de beans que as que poderiam, de outra maneira, ser mantidas simultaneamente na memória do servidor de aplicativos. Sob esse aspecto, um contêiner de EJB fornece serviços similares à memória virtual dentro de um sistema operacional.

O WebSphere Application Server fornece flexibilidade suficiente no gerenciamento de dados do banco de dados com beans de entidade. As definições de configuração Activate at e Load at dos EJBs de Entidade especificam como e quando carregar e armazenar os dados em cache a partir dos dados da linha de banco de dados correspondente de um enterprise bean. Essas definições de configuração fornecem a capacidade para especificar as Opções A, B ou C de armazenamento em cache de bean corporativo, conforme determinado nas especificações do EJB 1.1. Você pode configurar essas definições com as ferramentas de montagem. Para ler mais sobre como utilizar as ferramentas de montagem, consulte o centro de informações da ferramenta de montagem.

Entre transações, o estado de um bean de entidade pode ser armazenado em cache. O contêiner de EJB suporta as opções A, B e C de armazenamento em cache.
  • Com a opção A de armazenamento em cache, o servidor de aplicativos supõe que o bean de entidade é utilizado dentro de um único contêiner. Os clientes desse bean devem direcionar seus pedidos para a instância do bean dentro desse contêiner. O bean de entidade possui acesso exclusivo ao banco de dados subjacente, o que significa que o bean não pode ser clonado ou participar do gerenciamento de carga de trabalho se a opção A de armazenamento em cache for utilizada.
    Se você pretende utilizar cenários de leitura, o produto fornece uma variação alternativa de alto desempenho dos beans de entidade da opção A. Essa opção de armazenamento em cache é chamada de Multiencadeado de Leitura. Semelhante ao comportamento da opção A padrão, o contêiner EJB continua a ativar o bean apenas uma vez e o deixa ativo até o contêiner EJB precisar de espaço no cache da instância ativa. No entanto, o contêiner EJB difere da opção A padrão nos seguintes comportamentos:
    • Ele recarrega o estado do bean do armazenamento persistente periodicamente em resposta ao usuário que está chamando um método nele para captar quaisquer alterações que possam ter sido feitas no armazenamento persistente desde o último carregamento do bean. É possível configurar essa função por meio de uma configuração Intervalo de Recarregamento no descritor de implementação do bean. Para obter mais informações, consulte o tópico Desenvolvendo Beans de Entidade Somente Leitura.
    • O estado do bean não é gravado no armazenamento persistente pelo contêiner de EJB no final da transação nem o método ejbStore() do bean é chamado.
    • O contêiner de EJB permite chamadas de métodos de mais de um cliente (encadeamento) na mesma instância de bean. Isso difere do componente EJB padrão para os internos de um bean. Você deve lembrar-se desse aspecto ao desenvolver seu bean e assegurar-se de que qualquer lógica nos métodos de negócios do bean seja totalmente thread-safe.
  • Com a opção B de armazenamento em cache, o bean inteiro permanece ativo no cache por toda a transação mas é recarregado no início de cada chamada de método.
  • Com o armazenamento em cache da opção C (o padrão), o bean de entidade é sempre recarregado a partir do banco de dados no início de cada transação. Um cliente pode tentar acessar o bean e iniciar uma nova transação em qualquer contêiner que tenha sido configurado para hospedar esse bean. Isso é semelhante ao recurso de clustering de sessões descrito para sessões HTTP no sentido que o estado do bean de entidade é mantido em um banco de dados compartilhado que pode ser acessado a partir de qualquer servidor, quando necessário.

A opção A fornece o máximo desempenho do enterprise bean armazenando os dados d o banco de dados em cache fora do escopo da transação. Em geral, a Opção A só se aplica quando o contêiner EJB tem acesso exclusivo ao banco de dados fornecido. Caso contrário, a integridade de dados é comprometida. A Opção B fornece armazenamento em cache mais dinâmico das instâncias do objeto EJB de Entidade, que pode resultar em desempenho melhorado na Opção C, mas também resulta em mais uso de memória. A Opção C é a configuração real mais comum para EJBs de Entidade e é a configuração padrão.

A configuração Activate at especifica o ponto em que um enterprise bean é ativado e colocado no cache. A remoção do cache e a passivação também são controladas por esta configuração. Os valores válidos são Once e Transaction. A configuração Once indica que o bean é ativado ao ser acessado pela primeira vez no processo do servidor, e passivado (e removido do cache), a critério do contêiner, por exemplo, quando o cache fica cheio. A configuração Transaction indica que o bean é ativado no início de uma transação e passivado (e removido do cache) no final da transação. O valor-padrão é Transaction.

A configuração Load at especifica quando o bean carrega seu estado a partir do banco de dados. O valor desta propriedade implica se o contêiner tem acesso exclusivo ou compartilhado ao banco de dados. Os valores válidos são Activation e Transaction. Activation indica que o bean é carregado ao ser ativado e implica que o contêiner tem acesso exclusivo ao banco de dados. Transaction indica que o bean é carregado no início de uma transação e implica que o contêiner tenha acesso compartilhado ao banco de dados. O padrão é Transaction. As configurações das propriedades Activate at e Load at controlam as opções de confirmação que serão usadas. Para a Opção A (acesso exclusivo ao banco de dados), use Activate at = Once e Load at = Activation. Esta opção reduz a entrada/saída evitando chamadas na função ejbLoad, mas serializa todas as transações que acessam a instância do bean. A Opção A pode aumentar a utilização da memória mantendo mais objetos no cache, mas pode fornecer melhor tempo de resposta se as instâncias do bean não forem geralmente acessadas simultaneamente por várias transações.
Importante: Ao utilizar o WebSphere WebSphere Application Server, Network Deployment e o gerenciamento de carga de trabalho estar ativado, a Opção A não pode ser utilizada.

Você deve usar as configurações resultantes do uso das Opções B ou C. Para a Opção B (acesso ao banco de dados compartilhado), use Activate at = Once e Load at = Transaction. A Opção B pode aumentar a utilização da memória, mantendo mais objetos na cache. No entanto, como cada transação cria sua própria cópia de um objeto, pode haver várias cópias de uma instância na memória em um determinado momento (uma por transação), requerendo acesso ao banco de dados em cada transação. Se um enterprise bean contiver um número significativo de chamadas para uma função ejbActivate, a utilização da Opção B poderá ser benéfica, porque o objeto requerido já está no cache. Caso contrário, essa opção não fornecerá benefício significativo sobre a Opção A. Para a Opção C (acesso ao banco de dados compartilhado), use Activate at = Transaction e Load at = Transaction. Essa opção pode reduzir o uso de memória, mantendo menos objetos na cache. Entretanto, pode haver várias cópias de uma instância na memória em determinado momento (uma por transação). Esta opção pode reduzir a contenção de transações para instâncias de enterprise beans que são acessadas simultaneamente mas não atualizadas.

Este produto suporta a clonagem de objetos iniciais de bean de sessão com preservação de estado entre vários servidores de aplicativos. No entanto, ele não suporta a clonagem de uma instância específica de um bean de sessão com preservação de estado. Cada instância de um determinado bean de sessão com preservação de estado pode existir em apenas um servidor de aplicativos e pode ser acessada apenas direcionando os pedidos para esse servidor de aplicativos específico. As informações de estado para um bean de sessão com preservação de estado não podem ser mantidas entre vários membros de um cluster de servidores. No entanto, a ativação do failover do bean de sessão com preservação de estado e a configuração do contêiner de EJB para utilizar a replicação de memória à memória ativa o failover do bean de sessão com preservação de estado para ser replicado a outros servidores no cluster, para que o failover possa ocorrer para o servidor de backup, se o servidor principal para um bean de sessão com preservação de estado parar por alguma razão. Para obter informações adicionais sobre o failover do bean de sessão stateful, consulte Failover do Bean de Sessão Stateful do Contêiner EJB.

Por padrão, um contêiner de EJB é executado no modo inicialização rápida. A lógica de inicialização do contêiner EJB atrasa o carregamento e o processamento de todos os tipos de EJB, exceto Beans Acionados por Mensagens, porque beans acionados por mensagens devem existir antes que mensagens sejam postadas para eles; Beans de Inicialização, os quais devem ser processados quando o servidor inicia; e tipos de EJB que você especifica para inicializar quando o servidor inicia. .

Todas as outras inicializações de EJB são retardadas até a primeiro uso do tipo de EJB. Ao utilizar interfaces locais, o primeiro uso é quando você executa um método InitialContext.lookup para o tipo. Para interfaces remotas, é quando você chama o primeiro método em um EJB ou no Início.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_ecnt
Nome do arquivo: cejb_ecnt.html