Se a transação envolve todo o sistema, e não apenas lá o SGBD, você deve cudiar de transações em um lugar acima dos DAOs. Do contrário você só tem transacionamento para persistência.
Shoes
[quote=pcalcado][quote=Thiago Senna]
Uma dúvida recente que tive e que não está completamente solucionada é: Realmente devo controlar a tranzação no controle? Ou controle a tranzação no DAO?
Por exemplo, se o controle da tranzação fica no controle, como vc faz para saber se a persistência que vc está fazendo é em um MySQL, PostgreSQL, XML, Arquivo e etc…???
[/quote]
Se a transação envolve todo o sistema, e não apenas lá o SGBD, você deve cudiar de transações em um lugar acima dos DAOs. Do contrário você só tem transacionamento para persistência.
Shoes[/quote]
E o que seria em cima dos DAO’s??? Seria por exemplo eu utilizar um Façade para acessar os DAO’s?
Thiago
Seria. Use um Session Value Holder Factory Delegate para guardar a implementacao do Factory Delegate, que te da um Business Facade que esconde um Session Facade que delega pra um Singleton Data Access Object. Pra esse ultimo Facade voce passa uma serie de Data Transfer Objects inicializados pelo seu Business Delegate, que eh chamado pelo Front Controller e validado pelo Controller. Dai, eh soh pegar o Plumb Projectile Thrower Facade, apontar pro Inferior Limb Delegate, e disparar.
Oloco meu! :shock:
Posta um exemplo ai!!! 
Olá GUJ’s…
Relaxem que não vou perguntar neste post sobre este assunto…
Estou lendo este livro aqui
que tem nada a ver com swing… mas me fez entender melhor o que vcs tanto tentaram dizer nos posts anteriores, inclusive este em específico:
Cara meu… eu realmente estava dominado pelo lado negro da força! Tinha tomado uma overdose de design patterns e não conseguia imaginar um projeto mesmo que simple que não usasse essas merdas…
Também separei um tempo para dar uma olhada em alguns projetos open source e vi como se dá para resolver a maior parte dos meus problemas usando POJO… Agora só falta mesmo é experiência…
Valeu GUJ’s!
Thiago
Sei lá, o caso não é usar ou não patterns, é não procurar meter patterns onde eles não foram chamados 
Colocar toda a coleção do “Padrões de Projeto” ou da coleção do Martin Fowler, não vai resolver o problema, é só ver o que o mestre Jedi Gamma falou:
http://www.artima.com/lejava/articles/gammadp.html
Sobre as transações, a parada seria mais ou menos o seguinte, imagine que você tem que, antes de confirmar uma venda, garantir que o cartão do cliente é válido, a transação da venda só pode ser concluída quando você obtiver a resposta da prestadora dizendo que está tudo “livre”.
O que você faz? Diz pro cliente que a compra está aguardando confirmação e deixa alguém esperando pela mensagem (olha o JMS aqui ó), quando a mensagem chegar, você vê se tá liberado ou não e “termina” a transação. Isso é um caso onde a transação não está no banco de dados. Mas como o Phillip disse, se a transação é só no banco, ela deveria estar dentro dos seus DAOs, não precisa se extender não.
Desse modo, como não cair no anti-pattern “transaction (session) per operation” ?
Olá
Você pdoe manter a transação aberta se seu DAO possuir informação de estado. A questão é que não há porque essa transação deixar a camada de persistência.
Desse modo, como não cair no anti-pattern “transaction (session) per operation” ?
[/quote]
Olha, se você tá numa aplicação web, guarda a sessão e a transação em uma thread local e fecha com um filtro no fim do serviço, se você tá numa aplicação desktop usa aspectos pra pegar o fim de um método de serviço qualquer e fecha a sessão e a transação (também em uma tread local).
E qual o problema de se ter “transaction per operation” quando você está usando um pool de conexões? Elas não vão ser abertas e fechadas a todo o instante, eu acredito que o impacto seja mínimo dentro do sistema.
Outra coisa Phillip, como é que dá pra controlar isso usando estados no Dao, eu chamo um método qualquer pra “fechar” tudo no dao quando terminar?