Concorrência de EJBs aos recursos

2 respostas
E

Eu tenho uma grande dúvida sobre a concorrência dos Beans aos recursos. Supondo que eu utilize um Stateless Bean que faça usa de um recurso no container:

  • O Bean verifica se o recurso existe através do método lookup da class InitialContext;
  • Se o recurso existe, faz uso do mesmo;
  • Se o recurso não existe, instancia a classe Recurso e coloca no container através do métido bind da classe InitialContext.

Supondo que a classe Recurso contenha informações que são lidas e alteradas por este e outros Stateless Beans. Como fica a concorrência ao acesso à instância da classe Recurso? O que vai ocorrer se 2 instâncias do meu Bean acessarem a instância de Recurso ao mesmo tempo? O fato de eu armazenar o objeto no container através do bind já me garante este controle ou precisaria fazer um controle manual?

2 Respostas

J

Qualquer objeto q for acessado por mais de uma thread precisa ser ThreadSafe, ou seja:

  1. Ele NAO pode guardar estado(ie atributos);

ou

  1. Se possivel, utilize as bibliotecas de acesso concorrente do java.util.concurrent, q garantem integridade e performance no multiplo acesso a recursos compartilhados com uso de memoria razoavel;

ou

  1. Guardando estado, os valores de seus atributos precisam ser acessados de forma sincrona. Existem diversos patterns descritos no livro effective java q vc pode aplicar nessa situacao.

Prefira 1, senao 2, e se nao houver jeito 3. Tudo depende de seus requisitos de performance e desenho da solucao.

E

julioviegas:
Qualquer objeto q for acessado por mais de uma thread precisa ser ThreadSafe, ou seja:

  1. Ele NAO pode guardar estado(ie atributos);

ou

  1. Se possivel, utilize as bibliotecas de acesso concorrente do java.util.concurrent, q garantem integridade e performance no multiplo acesso a recursos compartilhados com uso de memoria razoavel;

ou

  1. Guardando estado, os valores de seus atributos precisam ser acessados de forma sincrona. Existem diversos patterns descritos no livro effective java q vc pode aplicar nessa situacao.

Prefira 1, senao 2, e se nao houver jeito 3. Tudo depende de seus requisitos de performance e desenho da solucao.

Beleza Júlio, entendi. Agora e no caso desta classe ser um Pool de Conexões JDBC, isto é, uma classe que implementa a interface javax.sql.DataSource? Não é pra ela controlar a concorrência automaticamente?
Eu uso banco de dados Firebird, cujo driver JDBC é o JayBird e uso Glassfish. Conforme já expliquei em outra mensagem aqui do GUJ, não consegui configurar um Connection Pool no próprio Glassfish porque o Glassfish usa a propriedade DatabaseName para o nome do banco e o JayBird só tem a propriedade Database. Resumindo, o Glassfish não conecta no meu banco. Se isto tivesse funcionado, eu faria conforme o tutorial J2EE da Sun recomenda, que é injetar o ConnectionPool diretamente no Bean e obter uma conexão, como neste exemplo do próprio tutorial:

<a class="mention" href="/u/resource">@Resource</a> javax.sql.DataSource catalogDS;

public getProductsByCategory() {

// get a connection and execute the query

Connection conn = catalogDS.getConnection();

…

}

Porém, como não funcionou, tive que fazer isso na mão, da seguinte maneira (dei uma resumida):

InitialContext context = new InitialContext();

try

{

dataSource = (DataSource) context.lookup(jdbc/MeuBanco);

}

catch (NamingException erro)

{

dataSource = null;

}

if (dataSource == null)

{

FBWrappingDataSource dataSource = new FBWrappingDataSource();

context.bind(jdbc/MeuBanco”, dataSource);

}

Connection connection = dataSource.getConnection();

Fazendo isso é o mesmo do que com injeção de recursos ou vou precisar fazer um controle manual de concorrência conforme você explicou?

Criado 25 de novembro de 2008
Ultima resposta 25 de nov. de 2008
Respostas 2
Participantes 2