[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico] [Índice de assunto]

Re: [reverbel-sma] Dúvidas

On 8/14/06, Rafael de F. Ferreira <rafael@xxxxxxxxxxxxxxxxxx> wrote: 
Então os beans stateless na verdade só não mantém estado de sessão com
o cliente, mas tem permissão para manter um estado de instância. O
único caso de uso que eu consigo imaginar para isso é fazer um cache
meia-boca de alguma computação mais cara. Meia-boca porque o escopo de
um cache desses seria limitado a somente uma instância da
implementação. Devem existir outros casos de uso que eu não
considerei, alguém tem sugestões?


Cada instância de stateless session bean (SLSB) pode possuir uma conexão
com um banco de dados ou outro sistema externo. Nesse caso o campo (não
estático) com a conexão seria inicializado logo após a criação de uma
instância de SLSB e antes da adição dessa instância ao pool de SLSBs.
Embora cada instância possua sua própria conexão, todas essas conexões
devem ser equivalentes (por exemplo, todas elas devem ser conexões com o
mesmo BD). Assim a conexão empregada não faz diferença para os clientes
do SLSB.

Se os beans fossem obrigados a serem totalmente desprovidos de estado,
então eu acredito que não haveria problemas de concorrência, uma vez
que não haveria nenhum dado compartilhado para sincronizar. Nesse caso
eu acho que não seria preciso fazer pooling dos objetos - uma
instância seria suficiente.


Correto. Em muitos casos o pooling de instâncias de SLSBs é "overkill".
No caso do exemplo acima, ele faz sentido. Se houvesse uma só instância
e se o acesso a ela fosse concorrente, então não adiantaria guardar num
campo da instância (ou mesmo num campo estático) uma conexão aberta,
pois as chamadas concorrentes à instância gerariam acessos concorrentes
ao BD (ou a outro sistema externo) através da mesma conexão. Claro que
isso não funcionaria.

Para quem conhece servlets, é interessante comparar os modelos:

Servlet: uma instância só, com acessos concorrentes à instância.

SLSB: pool com múltiplas instâncias equivalentes, não havendo
      concorrência no acesso a cada instância individual. Podem haver
      acessos concorrentes a instâncias diferentes.

No caso do exemplo acima, ocorreriam acessos concorrentes ao mesmo BD
(ou sistema externo). Como esses acessos seriam feitos através de
conexões diferentes, a responsabilidade pelo controle de concorrência
seria do BD.

Reverbel