Dúvida estrutural de EJB

Quando a carga do servidor aumenta, o numero de instancias do seu session bean atendendo aos clientes.
Existem servidores de aplicacao que permitem definir o numero de instancias do seu session bean que devem permanecer em memória e tambem um limite maximo de session beans atendendo as requisições.

Note que o Bean não precisa saber quantos clientes estão acessando ele, quem tem essa informação e sabe lidar com a carga é o container (JBoss, Glassfish e etc). E o Bean não é multi-thread e nem pode fazer acesso a métodos relacionados com threading, isso é responsabilidade do container também.

[]´s Marco.

Note que o Bean não precisa saber quantos clientes estão acessando ele, quem tem essa informação e sabe lidar com a carga é o container (JBoss, Glassfish e etc). E o Bean não é multi-thread e nem pode fazer acesso a métodos relacionados com threading, isso é responsabilidade do container também.

Então, mas no caso do meu Stateless Bean acessar e alterar um recurso do container, esta alteração precisa ser thread safing?

Quanto ao Bean não ser multi-thread, como funciona quando existem dezenas de acessos simultâneos ao mesmo bean? Eles entram numa fila?

eliflavio:

Note que o Bean não precisa saber quantos clientes estão acessando ele, quem tem essa informação e sabe lidar com a carga é o container (JBoss, Glassfish e etc). E o Bean não é multi-thread e nem pode fazer acesso a métodos relacionados com threading, isso é responsabilidade do container também.

Então, mas no caso do meu Stateless Bean acessar e alterar um recurso do container, esta alteração precisa ser thread safing?

Quanto ao Bean não ser multi-thread, como funciona quando existem dezenas de acessos simultâneos ao mesmo bean? Eles entram numa fila?

Não sei exatamente de qual recurso do container você está falando, mas threading é uma preocupação do container não do Bean.

O container mantém um pool de Beans, quando os clientes acesso um Bean o container passa a chamada para o Bean. Vou procurar ser mais claro.

Imagine um Stateless Bean com dois métodos
1: double cmToInch(double cm) // converte centimetros em polegadas,
2: double inchToCm(double inch) // converte polegadas em centimetros.

Como estamos falando de um Stateless ele não precisa ficar dedicado a um cliente exclusivamente durante todo seu ciclo de vida ele pode ser utilizado pelo cliente A para converter de cm para inches e logo depois para o cliente B para converter de inches para cm. O que acontece é que o container criar várias instâncias e as mantém na memória, quando um cliente chama um método neste bean o container pega um bean livre e chama o método requisitado, logo que o método acaba o container pode pegar este mesmo bean e usar para outro cliente e assim por diante.

Pense da seguinte forma imagine o container como um caixa de uma lanchonete com um número X de maquinas de débito. Os clientes vão chegando para pagar e o caixa vai alocando cada maquininha para cada cliente. (Isso seria a utilização do Pool de maquininhas). Conforme os comprovantes são emitidos, seja débito ou crédito, o caixa passa a máquina para o outro cliente.
Note que a máquina é Stateless, ela não liga para o cliente assim que a operação termina (no caso o método). Essa é a parte que muita gente confunde. O container não tira o Bean do cliente, ou troca, durante o método (isso levaria a problemas de threading) ele espera o método acabar e então aloca para outro cliente.

Bom, deu para perceber que o caixa consegue atender um número X de clientes simultaneamente, que corresponde ao número de máquinas que ele tem (tamanho do pool), os outros ficam esperando. Se ele tiver outras máquinas na gaveta ele pode começar a ligá-las quando o movimento aumenta (instanciar novos Beans).

enfim, deu para ter uma idéia?
[]´s Marco.

Quando existem inumeros acessos simultaneos, o servidor de aplicação instancia multiplos objetos do seu session bean e cada objeto cuida de uma requisicao. Portando o atendimento as requisicoes é feita em paralelo.

Você nao pode utilizar thread nos session beans porque as threads sao gerenciadas pela JVM enquanto os session beans são gerenciados pelo container.

Sobre as requisições disputarem os mesmos recursos, o coitainer é responsavel por gerenciar os servicos dele. Agora se o recurso é algum criado pelo usuario, como um cache de catalogo de produtos, fica a cargo do usuário definir mecanismo para ter acesso concorrente sem problemas.

mavcunha:

Não sei exatamente de qual recurso do container você está falando, mas threading é uma preocupação do container não do Bean.

O container mantém um pool de Beans, quando os clientes acesso um Bean o container passa a chamada para o Bean. Vou procurar ser mais claro.

Imagine um Stateless Bean com dois métodos
1: double cmToInch(double cm) // converte centimetros em polegadas,
2: double inchToCm(double inch) // converte polegadas em centimetros.

Como estamos falando de um Stateless ele não precisa ficar dedicado a um cliente exclusivamente durante todo seu ciclo de vida ele pode ser utilizado pelo cliente A para converter de cm para inches e logo depois para o cliente B para converter de inches para cm. O que acontece é que o container criar várias instâncias e as mantém na memória, quando um cliente chama um método neste bean o container pega um bean livre e chama o método requisitado, logo que o método acaba o container pode pegar este mesmo bean e usar para outro cliente e assim por diante.

Pense da seguinte forma imagine o container como um caixa de uma lanchonete com um número X de maquinas de débito. Os clientes vão chegando para pagar e o caixa vai alocando cada maquininha para cada cliente. (Isso seria a utilização do Pool de maquininhas). Conforme os comprovantes são emitidos, seja débito ou crédito, o caixa passa a máquina para o outro cliente.
Note que a máquina é Stateless, ela não liga para o cliente assim que a operação termina (no caso o método). Essa é a parte que muita gente confunde. O container não tira o Bean do cliente, ou troca, durante o método (isso levaria a problemas de threading) ele espera o método acabar e então aloca para outro cliente.

Bom, deu para perceber que o caixa consegue atender um número X de clientes simultaneamente, que corresponde ao número de máquinas que ele tem (tamanho do pool), os outros ficam esperando. Se ele tiver outras máquinas na gaveta ele pode começar a ligá-las quando o movimento aumenta (instanciar novos Beans).

enfim, deu para ter uma idéia?
[]´s Marco.

Entendi sim. Obrigado.

mauricio.miranda:

Quando existem inumeros acessos simultaneos, o servidor de aplicação instancia multiplos objetos do seu session bean e cada objeto cuida de uma requisicao. Portando o atendimento as requisicoes é feita em paralelo.

Você nao pode utilizar thread nos session beans porque as threads sao gerenciadas pela JVM enquanto os session beans são gerenciados pelo container.

Sobre as requisições disputarem os mesmos recursos, o coitainer é responsavel por gerenciar os servicos dele. Agora se o recurso é algum criado pelo usuario, como um cache de catalogo de produtos, fica a cargo do usuário definir mecanismo para ter acesso concorrente sem problemas.

Vou criar um controle de usuários logados, armazenando o código, nome, data e hora de login e outras informações. Meu sistema precisa saber se um usuário já está logado ou não, e vai precisa enviar mensagens para os usuários. Estou em dúvida em relação a onde armazenar os usuários logados. O que vocês recomendariam? Banco de dados? Este esquema de cache que você citou? Ou alguma outra maneira?

Eu recomendo utilizar banco de dados pois é rápido e seguro e não demanda esforços extras como criar um cache.

mauricio.miranda:

Eu recomendo utilizar banco de dados pois é rápido e seguro e não demanda esforços extras como criar um cache.

Concordo com você, porém, para cada usuário logado no sistema, terei que armazenar também uma conexão Socket, aí não tem como guardar no banco de dados. Estou criando um sistema de monitoramento de alarmes, quando chega um evento qualquer, por exemplo um disparo de alarme, o servidor precisa conhecer todos os usuários logados, saber quem está disponível e então enviar um pacote para o cliente via socket para ele saber que tem um disparo de alarme para ele tratar. Se eu fizer isso tudo por banco de dados, sem usar socket, a comunicação não será em tempo real, sendo que o cliente precisaria ficar o tempo todo solicitando uma consulta no banco de dados para saber se chegou algo. Se eu fizer 1 consulta por segundo, considerando diversos clientes, vai sobrecarregar o servidor. Se aumentar muito o tempo haverá um delay que poderá ser crucial no caso de um roubo.
Sendo assim, a alternativa mais viável que conheço é usar socket mesmo.

Acho que as duas soluções são complementares.
Voce pode verificar se o usuario esta autenticado utilizando banco de dados(essa operacao é realizada na ordem dos milisegundos).
e depois vc envia as mensagens para os usuarios via o seu socket.

E sobre performance essa é uma questao que especulacao nao resolve nada, voce deve fazer um prototipo, testar e validar sua arquitetura tendo assim base solida para desenvolver toda sua aplicacao