Propagar instância nas chamadas EJB

Olá amigo, vale a pena vc ver a nova especificação ejb 3.1.
Vc poderia usar o @Singleton para determinar que seu bean seja unico no contexto da app ejb. Mas cuidado com a concorrencia sobre o bean…
fallow

a aplicação roda com ejb 3 mudar para o 3.1 é outra historia,

eu to precisando de algo isolado para cada chamada, algo a nível de transação, vou carregar informações no banco e estas vão valer para toda a chamada, se propagando para todos os ejbs usados durante o processo

Vc ja pensou em usar o mem cache? OU algo similar, qual seria o objetivo?

tenho um sistema de parâmetros do sistema que junta xml com informaçãos no banco, em niveis (usuario,empresa,geral),
se ficar carregando isto toda vida que precisar, torna os processos lentos, se carregar uma so vez e em todo processo aproveitar esta carga, se torna mais eficiente,

em um sistema com uma arquitetura mais antiga usando commands fiz algo parecido e ficou muito bom, para cada command que ele chamava passava uma instancia de classe controladora, mais agora com ejb3 não tem mais esta classe

Entendi, no entanto se é uma parte do sistema de parametros de configuração variaveis eu recomendaria a API commons-configuration da apache, realmente é bem interessante e talvez valha a pena dar uma olhada.

Ou considere usar o padrão Factory no seu projeto, seria outra alternativa. OK!
Fallow

Não sei se eu entendi direito o problema, mas não seria possível passar os dados necessários como parâmetro entre as chamadas encadeadas (de preferência um objeto contendo todas as configurações).

Assim fica independente de qualquer estado no servidor.

é isto mesmo, mais queria deixar isto transparente, para evitar a refatoração do processos já existentes.

Tem duas soluções “certinhas” e uma “mais fácil”.

As maneiras mais corretas são:

1. Como foi dito antes, usar um servidor de cache. Veja um exemplo: http://www.objectzilla.com.br/2009/05/02/ja-usou-memcached/
2. Guardar e recuperar o objeto desejado através de JNDI.

Agora que já falamos da solução mais certinha vamos falar da gambiarra rsrs

Pode ser feito assim:

• Criar uma variável de instância no EJB, contendo as configurações.

• Um método acessor que faz lazy loading da configuracao, como o seguinte:

private Configuracao getConfiguracao() { if (this.config == null) { // Primeiro acesso. this.config = // Faz todo o trabalho pesado de carregar a configuração } return config; }
Depois, no código dos métodos do EJB propriamente dito, chamaria sempre pelo getConfiguracao(), e nunca pela variável direto.

O que acontecerá então é: sempre que uma instância do EJB acessar pela primeira vez esse objeto, ele será carregado e mantido em cache. Nas próximas essa mesma instância é reutilizada.
É verdade que o trabalho de carregamento será repetido algumas vezes, mas não a cada chamada, só na primeira vez de cada instância. Quando todas as instâncias do pool tiverem sido usadas pelo menos uma vez, os dados não precisam ser mais consultados.