Se você tem apenas 1 EJB no seu pool para atender 100 requests, você vai atender 1 request e deixar 99 aguardando na fila.
Se você tem 10 EJBs no seu pool para atender 10 requests cada 1, você vai atender 10 requests de cada vez (10 EJBs x 1 request) e deixar 90 requests na fila (9 requests em cada uma das 10 filas).
[]'s
Marco Campêlo
jprogrammer, o genesis implementa exatamente essa solução, mas de forma totalmente não intrusiva. Você pode ter um POJO e chamar seus métodos normalmente e aqueles que devem ser executados dentro de um EJB são 
Algo mais ou menos assim:
public class POJO {
/** @Remotable */
public void metodo() {
System.out.println("Metodo remoto");
}
}
// Codigo cliente
POJO pojo = new POJO();
// Executa o metodo remotamente
pojo.metodo();Então a questão do desempenho não seria o problema mas a transação.
Entendi.
Se depender de uma transação especial para o service é melhor criar uma EJB para ele. Caso contrário poderia deixar no genérico.
Mas que caso a transação teria um tratamento especial ?
Cada requisição geraria uma transação.
O container consegue tratar isso.
ex:
class FuncionarioService{
public void cadastrar(FuncionarioDTO)
{
// faz uma acao
// faz outra
// se falhar volta
}
}Mas esse método é chamado via reflection.
Se falar a chamada volta tudo.
edit:
Já me falaram que o Genesis parece suprir essa necessidade. Mas gostaria de saber se tem como fazer na raça para eu aprender.
É lógico que em um projeto eu adotaria ele.
Você já leu sobre os tipos diferentes de controle de transação que o container EJB oferece?
Imagine que você tem o serviço A que precisa do controle X e do serviço B que precisa do controle Y. Não vai ter como colocar esses dois serviços embaixo do mesmo GenericEJB.
Controle X poderia ser por exemplo criar uma nova transação sempre.
Controle Y poderia ser por exemplo aproveitar a transação já existente sempre.
[]'s
Marco Campêlo
Entendi.
Mas no seu caso a performance ficou legal ?
Então dê uma olhada no código que está no CVS e veja se consegue implementar você mesmo depois de fazer isso.
Se tá doido cara !
Não chega a tanto.
Eu to falando com essa estratégia que a gente está comentando.
Quando coloco posts como esse é simplesmente para gerar discussões que aumentem nosso conhecimento.
Só nessa história eu já estou entendendo bem mais como o container trabalha as instancias de EJB.
Não necessariamente eu irei usar isso.
Se a gente ficar use isso, use aquilo, pegue aquilo pronto nunca iremos entender como as coisas funcionam.
Agora não quer dizer que quero entender em níveis de bits.
Eu disse pra você não implementar? Eu realmente quis dizer: veja como foi feito, se você consegue entender e pergunte depois.
A melhor forma de evoluir em algo assim, se você não quer usar algo pronto, é ver como foi implementado, tentar entender a razão e questionar quais outras opções seriam possíveis.
Eu não sou tão sarcástico assim como você pensa… 
Sim, vamos, pq a gente pega as coisas prontas e olha como elas foram feitas caso quiser aprender. Aceite o fato de que vc nao precisa inventar coisas - voce pode muito bem ler sobre elas, pq praticamente todas as pequenas pecas que sao relevantes pra base do desenvolvimento de um sistema ja foram inventadas e estao amplamente documentadas e implementadas por ai. Se nao estao, ai sim voce tem uma oportunidade. Do contrario, lembre-se que codigo tambem eh literatura 
Nesse caso, da proxima ja avise antes “ei, eu tou com essa duvida, mas eu nao quero saber muito nao, quero so uma resposta nas coxas, bem mais ou menos, mesmo, pq eu nao tenho saco de entender o que voces dizem!” :mrgreen:
Cv eu sei porque vc está mogoado comigo.
É por causa do virtual proxy que eu disse que era um monte de código “inútil”.
Não falei isso por mal, apenas não vi a utilidade mas por ignorancia minha.
O intuito era saber qual era a a vantagem daquele código em relação ao Method.invoke.
Percebi que depois daquele post vc ficou magoado…
:oops:
Algumas correcoes:
E, agora, o conteudo do post:
A vantagem de usar Dynamic Proxies eh que voce nao precisa ficar passando os nomes dos servicos como Strings pra la e pra ca, jogando a checagem de tipos do compilador fora: voce pode usar interfaces de verdade, e testar o codigo mais facil tanto em Unit Isolation quanto em Unit Integration, alem de poder jogar o EJB fora e rodar os servicos localmente, se der na telha.
Alias, chamar isso de “EJB Generico” eh meio feinho. Nomes mais apropriados seriam InvokerEJB ou ServiceExecutorEJB.
Valeu cara.
Estou a berto a correções.
Não sou arquiteto de software.
Estou aprendendo e estou tentando formar minha própria “cabeça” em relação as metologias e quando um dia for arquiteto poderia fazer meu trabalho com qualidade e propriedade.
Porque tem muita gente com título de arquiteto que não sabe nada.
Faz um cursinho de UML e já sai dizendo que é analista/arquiteto.
Ve se isso pode ?
Sou programador.
Estou acostumado a fazer apenas coisas que me mandam.
[quote=LIPE]DualRpc! DualRpc!
DUAL RPC![/quote]
Legal. Não conhecia.
Mas li o FAQ e não senti muita firmeza no esquema de balanceamento e falha.
Parece que o foco da solução é para RPCs que precisam manter o estado. Não sei se há vantagens em utilizá-lo no caso de Stateless.
[]'s
Marco Campêlo
tenho trauma de RPC … mas gostei do projeto … tobookmarks