Gerenciamento de transações. Porque não no DAO?

noel,

ThreadLocal não elimina o uso de pool, apenas elimina o passa-passa de objetos entre os varios layers da aplicação. Com TL, eu faço +/- assim:

Quanto a Runnable, você tá confundindo a interface Runnable com a classe Thread. Usar a interface não implica em criar threads.

Veja que se você usa uma conecção por DAO, tuas operações não são transacionais, afinal todos precisam todas usar a mesma conecção.

Thread.start() Membro desde: 12/07/2005 12:46:51 Mensagens: 32 Offline

louds wrote:noel,

ThreadLocal não elimina o uso de pool, apenas elimina o passa-passa de objetos entre os varios layers da aplicação. Com TL, eu faço +/- assim:

try { threadLocal.put(pool.getConnection()); } finaly{ ((Connection)threadLocal.get()).close(); threadLocal.put(null); }

Quanto a Runnable, você tá confundindo a interface Runnable com a classe Thread. Usar a interface não implica em criar threads.

Veja que se você usa uma conecção por DAO, tuas operações não são transacionais, afinal todos precisam todas usar a mesma conecção.

Com relação ao Runnable me abstenho tamanha a minha ignorancia ...

e com relação a ThreadLocal, tudo resolvido, entendi .. hehehe ...

DAO e Transações não da certo, estou convencido ... hehehe .....

mas ficou uma duvida sobre ThreadLocal ...

qualquer um pode pegar a sessão q eu coloquei na ThreadLocal?

Normalmente uma ThreadLocal é uma variavel estática com getter público e setter não-público. Ou seja, todo mundo pode pegar.

louds wrote:Normalmente uma ThreadLocal é uma variavel estática com getter público e setter não-público. Ou seja, todo mundo pode pegar.

Dentro da mesma thread.

This message was edited 1 time. Last update was at 18/07/2005 16:55:10

Já me perguntaram em PM, como eu implementei meu controle transacional. Vou colocar o código aqui. É bem simples!

Transaction.java

package my.trans;

import java.sql.*;
import java.util.Map;
import javax.sql.DataSource;

public class Transaction {
    private Connection conn;
    private boolean oldAutCommit;
    
    public Transaction() {
    }
    
    public void end() {
        TransactionManager.endTransaction();
        if (this.conn != null) {
            try { this.conn.setAutoCommit( this.oldAutoCommit );  } 
            catch (SQLException e) {}
            try { this.conn.close(); } 
            catch (SQLException e) {}
        }
    }
    
    public Connection getConnection(String dataSource) throws Exception {
        if (this.conn == null) {
            try {
                synchronized (this) {
                    this.oldAutoCommit = this.conn.getAutoCommit();
                    this.conn = pegaAConexaoDeAlgumLugar();
                    //seja de um POOL, via JNDI etc...
                    this.conn.setAutoCommit(false);
                }
            }
        }
        return new TransactionConnection(this.conn);
    }

public void rollback() throws Exception {
         this.conn.rollback();
    }
    
    public void commit() throws Exception {
         this.conn.commit();
    }
}

TransactionConnection.java

package my.trans;

import java.sql.*;

protected class TransactionConnection implements Connection {
    private Connection conn;
    
    protected TransactionConnection(Connection conn) {
        if (conn == null) {
            throw new IllegalArgumentException();
        }
        this.conn = conn;
    }

public int getHoldability() throws SQLException {
        return conn.getHoldability();
    }

public int getTransactionIsolation() throws SQLException {
        return conn.getTransactionIsolation();
    }

public void clearWarnings() throws SQLException {
        conn.clearWarnings();
    }

public void close() throws SQLException {
        //conn.close();
    }

public void commit() throws SQLException {
        //conn.commit();
    }

public void rollback() throws SQLException {
        //conn.rollback();
    }

public boolean getAutoCommit() throws SQLException {
        //return conn.getAutoCommit();
        return false;
    }

public boolean isClosed() throws SQLException {
        return conn.isClosed();
    }

public boolean isReadOnly() throws SQLException {
        return conn.isReadOnly();
    }

public void setHoldability(int arg0) throws SQLException {
        conn.setHoldability(arg0);
    }

public void setTransactionIsolation(int arg0) throws SQLException {
        conn.setTransactionIsolation(arg0);
    }

public void setAutoCommit(boolean arg0) throws SQLException {
        //conn.setAutoCommit(arg0);
    }

public void setReadOnly(boolean arg0) throws SQLException {
        conn.setReadOnly(arg0);
    }

public String getCatalog() throws SQLException {
        return conn.getCatalog();
    }

public void setCatalog(String arg0) throws SQLException {
        conn.setCatalog(arg0);
    }

public DatabaseMetaData getMetaData() throws SQLException {
        return conn.getMetaData();
    }

public SQLWarning getWarnings() throws SQLException {
        return conn.getWarnings();
    }

public Savepoint setSavepoint() throws SQLException {
        return conn.setSavepoint();
    }

public void releaseSavepoint(Savepoint arg0) throws SQLException {
        conn.releaseSavepoint(arg0);
    }

public void rollback(Savepoint arg0) throws SQLException {
        //conn.rollback(arg0);
    }

public Statement createStatement() throws SQLException {
        return conn.createStatement();
    }

public Statement createStatement(int arg0, int arg1) throws SQLException {
        return conn.createStatement(arg0, arg1);
    }

public Statement createStatement(int arg0, int arg1, int arg2) throws SQLException {
        return conn.createStatement(arg0, arg1, arg2);
    }

public Map getTypeMap() throws SQLException {
        return conn.getTypeMap();
    }

public void setTypeMap(Map arg0) throws SQLException {
        conn.setTypeMap(arg0);
    }

public String nativeSQL(String arg0) throws SQLException {
        return conn.nativeSQL(arg0);
    }

public CallableStatement prepareCall(String arg0) throws SQLException {
        return conn.prepareCall(arg0);
    }

public CallableStatement prepareCall(String arg0, int arg1, int arg2) throws SQLException {
        return conn.prepareCall(arg0, arg1, arg2);
    }

public CallableStatement prepareCall(String arg0, int arg1, int arg2, int arg3) throws SQLException {
        return conn.prepareCall(arg0, arg1, arg2, arg3);
    }

public PreparedStatement prepareStatement(String arg0) throws SQLException {
        return conn.prepareStatement(arg0);
    }

public PreparedStatement prepareStatement(String arg0, int arg1) throws SQLException {
        return conn.prepareStatement(arg0, arg1);
    }

public PreparedStatement prepareStatement(String arg0, int arg1, int arg2) throws SQLException {
        return conn.prepareStatement(arg0, arg1, arg2);
    }

public PreparedStatement prepareStatement(String arg0, int arg1, int arg2, int arg3) throws SQLException {
        return conn.prepareStatement(arg0, arg1, arg2, arg3);
    }

public PreparedStatement prepareStatement(String arg0, int[] arg1) throws SQLException {
        return conn.prepareStatement(arg0, arg1);
    }

public Savepoint setSavepoint(String arg0) throws SQLException {
        return conn.setSavepoint(arg0);
    }

public PreparedStatement prepareStatement(String arg0, String[] arg1) throws SQLException {
        return conn.prepareStatement(arg0, arg1);
    }
    
}

TransactionManager .java

No DAO:

E para usar:

Pode ser mais abstraído, mas basicamente é isso.

Virtual Machine Man Membro desde: 21/08/2002 03:53:28 Mensagens: 661 Offline

Louds, como vc faz com Exceptions que seu runnable tem que lançar? Tudo unchecked?

O esqueminha do Tiny Marbles é exatamente assim, mas ainda não consegui inventar um esquema decente de lançar exceções arbitrárias.

JavaTeenager Membro desde: 18/07/2006 10:25:29 Mensagens: 150 Offline

po.. sinceramente..
codigo de infra-estrutura é chato pra caramba,,

porque nao usar um EJB session bean ou uma fachada pojo com Spring?

na forma declarativa fica muito mais facil de resolver problemas mais complexos, pois voce seta 1 tipo de atributo de comportamento pra cada componente ou chamada (required, required new, supported etc,,)

falow

dukejeffrie wrote:Louds, como vc faz com Exceptions que seu runnable tem que lançar? Tudo unchecked?

O esqueminha do Tiny Marbles é exatamente assim, mas ainda não consegui inventar um esquema decente de lançar exceções arbitrárias.

O runnable empacota todas exceptions como unchecked. Até pouco tempo a maioria dos casos eram "ou funcionou ou deu pau", então não existia um tratamento mais apurado para as exceptions lançadas.

Recentemente tive que implementar um caso no qual eu precisava executar transações aninhadas, tinha que diferenciar o tipo de erro ocorrido por uma unit-of-work para tomar uma decisão abort/retry/change.

Nesse caso eu passei a usar EDU.oswego.cs.dl.util.concurrent.Callable e a tratar exceptions usando uma Chain Of Responsibility com filtros que ou assimilavam a exception ou convertiam ela para uma mais util.

Felipe, usar EJB só para ter gerênciamento de transações é loucura, muita pentelhação e tralha por pouca coisa. Spring é legal, use no lugar de fazer na mão sempre que possivel, mas infelizmente o framework de suporte a Hibernate e transações precisa ser alterado (leia editar os fontes do Spring) se você quer suportar coisas como replicação, particionamento, fail-over ou stop/resume. Além do fato que em vários projetos usar Spring simplesmente não é uma opção (cliente não quer, equipe não sabe usar, gerênte cagou regra sobre...).

JavaTeenager Membro desde: 18/07/2006 10:25:29 Mensagens: 150 Offline

louds wrote:
Felipe, usar EJB só para ter gerênciamento de transações é loucura, muita pentelhação e tralha por pouca coisa. Spring é legal, use no lugar de fazer na mão sempre que possivel, mas infelizmente o framework de suporte a Hibernate e transações precisa ser alterado (leia editar os fontes do Spring) se você quer suportar coisas como replicação, particionamento, fail-over ou stop/resume. Além do fato que em vários projetos usar Spring simplesmente não é uma opção (cliente não quer, equipe não sabe usar, gerênte cagou regra sobre...).

só para isso é exagero mas nao loucura

e tb session beans sao moleza de implementar... diferente dos entity.. e alem do controle de transação trazem outras facilidades, que as vezes sao uteis

qto ao particionamento, replicação.. os DB´s deveriam cuidar disso pra nos de forma transparente não? a nao ser q vc replique ou fragmente na mao.. mas eu nunca vi isso

oq eu quis dizer.. é que escrevendo o codigo de transação (o controle dela), um caso um pouquinho mais elaborado, como usar + de 1 componente, ja pode ficar chato e com muito "codigozinho" pra implementar e dar manutencao..

tendo ferramentas que cuidam desse controle transacional pra nos.. pra que ficar implementando codigo pra isso? hehehe

felipecruz wrote:
só para isso é exagero mas nao loucura
e tb session beans sao moleza de implementar... diferente dos entity.. e alem do controle de transação trazem outras facilidades, que as vezes sao uteis

Sim, mas te obriga a usar um AS, eu não escrevo aplicações web/online a meses, entretanto tenho necessidades transacionais muito chatas. SLSB são uteis somente quando você tem um cenario que eles se encaixam, senão são um enorme entrave.

felipecruz wrote:
qto ao particionamento, replicação.. os DB´s deveriam cuidar disso pra nos de forma transparente não? a nao ser q vc replique ou fragmente na mao.. mas eu nunca vi isso

Replicação quem cuida de fazer é o banco mesmo, mas eu ainda tou para ver um driver JDBC que de forma transparente acesse as réplicas quando preciso fazer consultas apenas. Replicar o RDBMS faz, mas acessar as réplicas é problema da aplicação.

Particionamento em todos os casos que eu vi era gerenciado pela aplicação. Existem RDBMS que fazer isso, mas ou ainda são produtos beta (mysql), ou o custo é insanamente caro (imagine um deployment de 40 servidores oracle rac?), ou simplesmente não escalam (oracle rac tem um limite baixo no número de nós).

A maioria dos lugares que conheço que faz particionamento de dados, faz na camada de aplicação. Tou falando de sites como flickr e livejournal, por exemplo. A escalabilidade e os custos são muito boas como você pode verificar.

felipecruz wrote:
oq eu quis dizer.. é que escrevendo o codigo de transação (o controle dela), um caso um pouquinho mais elaborado, como usar + de 1 componente, ja pode ficar chato e com muito "codigozinho" pra implementar e dar manutencao..

tendo ferramentas que cuidam desse controle transacional pra nos.. pra que ficar implementando codigo pra isso? hehehe

Como menCionei, nem todos os casos existem ferramentas que atendem, ou então simplesmente não é possivel usá-las. Fora isso, concordo com você, não faz sentido escrever código de infra, que é chato e dificil, se já existem implementações por ai.

JavaTeenager Membro desde: 18/07/2006 10:25:29 Mensagens: 150 Offline

concordo com voce.. hehe mas oq vc descreveu são 20% dos casos no maximo

pra maioria das pessoas um spring ou EJB ja é suficiente!

o particionamento q vc menciono.. é logico e nao fisico.. por isso eles tao na camada de aplicação.. o particionamento fisico TEM q ser transparente.. se nao for tem algo de errado..

mas ai ja é fugir mto do topico ahuehua

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

Também acho que o gerenciamento de transações NÃO deve estar nos DAOs. Caso vc precise de dois ou mais DAOs para executar uma mesma transação, a implementação fica difícil.

Nesse caso, eu também optaria por usar um AS com EJBs. As vantagens são enormes!!!

O AS abstrai as funcionalidades de gerenciamento de transação. Além disso, a aderência aos padrões J2EE permite que vc escolha o AS que mais adeque-se às suas necessidades (hoje, os players fornecem o básico, descrito na especificação, e vão muito além quando o assunto é otimização).

Se vc precisar de segurança, ela está lá, é só ativar.
Se vc precisar de clusterização, ela está está lá, é só ativar.
Se vc precisa de load balancing, ele está lá, é só ativar.
Se vc precisar de transações distribuídas, sejam quão chatas elas forem, elas estão, é só ativar.
Se vc precisar trocar de AS, outros estarão lá, com suas vantagens e desvantagens.

Pq que reinventar a roda? Depois o pessoal fica reclamando das bombas que pegam de outros desenvolvedores que criam frameworks proprietários.

Taz wrote:Também acho que o gerenciamento de transações NÃO deve estar nos DAOs. Caso vc precise de dois ou mais DAOs para executar uma mesma transação, a implementação fica difícil.

Nesse caso, eu também optaria por usar um AS com EJBs. As vantagens são enormes!!!

O AS abstrai as funcionalidades de gerenciamento de transação. Além disso, a aderência aos padrões J2EE permite que vc escolha o AS que mais adeque-se às suas necessidades (hoje, os players fornecem o básico, descrito na especificação, e vão muito além quando o assunto é otimização).

Se vc precisar de segurança, ela está lá, é só ativar.
Se vc precisar de clusterização, ela está está lá, é só ativar.
Se vc precisa de load balancing, ele está lá, é só ativar.
Se vc precisar de transações distribuídas, sejam quão chatas elas forem, elas estão, é só ativar.
Se vc precisar trocar de AS, outros estarão lá, com suas vantagens e desvantagens.

Pq que reinventar a roda? Depois o pessoal fica reclamando das bombas que pegam de outros desenvolvedores que criam frameworks proprietários.

Cara, segurança definida no J2EE é muito, muito ruim. Qualquer coisa que não seja 'área protegida + form de login' não existe padrão, você é obrigado a utilizar extensões proprietárias. O clássico exemplo de implementar login programático na aplicação continua impossivel de forma padronizada.

Você não precisa de EJB ou um AS para usar clustering e load balancing, normalmente você está melhor usando outras soluções que não um application server para isso.

Se você precisar de transações distribuidas, usar um AS vai ser o menor dos teus problemas, então é melhor mesmo usar um.

Quanto a trocar de AS, esse teu argumento é brincadeira, nunca vi a migração de qualquer aplicação de media complexidade entre AS diferentes ser menos que um INFERNO. Normalmente já um problema enorme trocar a versão, de fornecedor então...

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

louds wrote:
Cara, segurança definida no J2EE é muito, muito ruim. Qualquer coisa que não seja 'área protegida + form de login' não existe padrão, você é obrigado a utilizar extensões proprietárias. O clássico exemplo de implementar login programático na aplicação continua impossivel de forma padronizada.

Acho que não. Autenticação é um dos aspectos de segurança (e talvez o mais simples!!!) tratados na J2EE.

louds wrote:
Você não precisa de EJB ou um AS para usar clustering e load balancing, normalmente você está melhor usando outras soluções que não um application server para isso.

Quais soluções? Como vc implementou?

louds wrote:
Quanto a trocar de AS, esse teu argumento é brincadeira, nunca vi a migração de qualquer aplicação de media complexidade entre AS diferentes ser menos que um INFERNO. Normalmente já um problema enorme trocar a versão, de fornecedor então...

Se foi um INFERNO é pq foram utilizados recursos proprietários. Se um arquiteto trabalha com o requisito de que a aplicação deve ser portável entre ASs, obviamente ele não vai deixar que o time de desenvolvimento utilize recursos proprietários. Além disso, a troca de AS tb não é muito frequente e, geralmente, as empresas estão contentes com os fornecedores que possuem atualmente.

Taz wrote:

louds wrote:
Cara, segurança definida no J2EE é muito, muito ruim. Qualquer coisa que não seja 'área protegida + form de login' não existe padrão, você é obrigado a utilizar extensões proprietárias. O clássico exemplo de implementar login programático na aplicação continua impossivel de forma padronizada.

Acho que não. Autenticação é um dos aspectos de segurança (e talvez o mais simples!!!) tratados na J2EE.

Bom, então me mostra como faço para implementar autenticação programática com j2ee 1.4? Não vou nem falar de autorização, pq o modelo é tão ruim que não permite, por exemplo, definir políticas de acesso por instância. Resumindo, o modelo de autenticação e autorização não é nenhum pouco plugavel ou extensivel.

Taz wrote:

louds wrote:
Você não precisa de EJB ou um AS para usar clustering e load balancing, normalmente você está melhor usando outras soluções que não um application server para isso.

Quais soluções? Como vc implementou?

Load balancing é muito melhor feito por uma solução de hardware ou um software especializado como o PLB. Clustering depende muito da arquitetura do projeto, como a maioria dos sistemas que trabalhei eram share-nothing, não utilizamos nada de especial. No resto o máximo que usamos foi um cache distribuido.

Taz wrote:

louds wrote:
Quanto a trocar de AS, esse teu argumento é brincadeira, nunca vi a migração de qualquer aplicação de media complexidade entre AS diferentes ser menos que um INFERNO. Normalmente já um problema enorme trocar a versão, de fornecedor então...

Se foi um INFERNO é pq foram utilizados recursos proprietários. Se um arquiteto trabalha com o requisito de que a aplicação deve ser portável entre ASs, obviamente ele não vai deixar que o time de desenvolvimento utilize recursos proprietários. Além disso, a troca de AS tb não é muito frequente e, geralmente, as empresas estão contentes com os fornecedores que possuem atualmente.

Negativo, toda migração de versões/fornecedores é um inferno pelos seguintes motivos:

A spec possui partes não especificadas, ou mal especificadas.

Containers diferentes, bugs diferentes.

Ninguém desenvolve aplicação J2EE, todo mundo desenvolve J2EE implementação xyz.

Moral da história, aplicações J2EE são muito mais facilmente portaveis que uma escrita em C++ e DCOM, por exemplo, mas não são a panaceia para o assunto.

Notícias, artigos e o maior fórum brasileiro sobre Java