> InitialContext ic = new InitialContext ( );
> DataSource ds = ( DataSource ) ic.lookup ( "java:comp/env/jdbc/DBName" );
> Connection con = ds.getConnection ( );
> con.setAutoCommit ( false );
Vc n�o deveria usar setAutocommit com CMT.
>
> Eu tenho as seguintes d�vidas:
> 1. A transa��o � "commitada" ou desfeita quando a conex�o � fechada
> ou o container faz algum tratamento que permite que a transa��o seja
> mantida aberta e que, quando for conclu�da (fim do m�todo CMT), �
> feito commit/rollback com a conex�o j� fechada?
N�o posso te dizer como isso *realmente* funciona, mas acho que tem algo a ver com o tlog da app server. Mas o commit � feito no contexto en n�o em cima de uma cone��o ae sim a cone��o j� deve estar retornado para o pool.
> 2. Quando fa�o um UPDATE no banco de dados, o registro � bloqueado
> (locked) (estou certo?). Este lock � mantido quando a conex�o �
> fechada, at� que o container d� o commit ou rollback na transa��o?
> Ou � perdido quando a conex�o � fechada?
Isso depende muito do Transaction Isolation level. Logicalmente somente pode ser feito um update no mesmo tempo, mas reads geralmente s�o permitidos. Se existe um update lock, isso � mantido durante a transa��o.
>
> 3. O container mant�m algum tipo de lock para os Entity Beans?
N�o obrigatoriamente, e geralmente n�o. Se fizer um select e em seguido um update, o ejbLoad � chamada num contexto transacional e depois ejbStore � chamada em outro contexto transacional, a n�o ser que utiliza um Statefull session bean e a transa��o encompasa v�rias metodos no mesmo sessionbean (BMT)
- [enterprise-list] Transa��es Jonatan Schroeder
- [enterprise-list] Transa��es Jonatan Schroeder
- [enterprise-list] Transa��es Jonatan Schroeder
- Re: [enterprise-list] Transa��es sven
- Re: [enterprise-list] Transa��es Jonatan Schroeder
- Re: [enterprise-list] Transa��es sven
- [enterprise-list] just a joke sven
- Re: [enterprise-list] Transa��es Jonatan Schroeder
