Transação x DAO

Galera,

Vi alguns controles de transação em algumas aplicações por aqui, mas não estou concordando muito com a forma como estão.
Tem app que quando precisa-se criar mais de um DAO ou fazer mais de uma operação com o banco, simplemente passando a conexao via set, para dentro do VO, onde exixste uma váriavel de Connnection, passa-se esse VO para o método do DAO, inserir(VO), e lá dentro verificam se essa variávle está null ou não para criar ou não outra conexão.

Também tem outra app em que as conexões são passadas no cabeçalho do método, inserir(AlgumaCoisa, conexão).

E uma que fiquei mais intrigado, é que a conexão é passada na criação do DAO, new DAO(conexão, flag), onde passam true ou false no flag, pra saber se vão ou não fechar essa conexão.

Enfim,
Como você geralemtne gerenciam suas transações quando necessitam de numa mesma conexão efetuar mais de uma operaçao com o banco, mais de uma instanciação de DAO, JTS, JTA, conexão no cabeçalho mesmo?

Uma maneira elegante, simples e certa de preferência

Agraço

Usando uma thread-bound Connection.

Em ambientes web tem um servlet-filter responsavel por gerenciar conexões e transações.

louds wrote:Usando uma thread-bound Connection.

Em ambientes web tem um servlet-filter responsavel por gerenciar conexões e transações.

seria uma aplicaçãozinha web, que vai rodar no tomcat por exemplo ou jetty como queiram.

Eu faço isso porque é a forma mais facil...

É só colocar num servlet filter para sempre executar o release ao final do processamento e pronto. Veja que o exemplo tá bem simplificado pois não preve coisas como checkpointing, early commit/rollback e qualquer requisito de transacional que não seja o básico (1 con - 1 tx local - 0 cp).

Nos daos ai é só fazer assim:

louds wrote:Eu faço isso porque é a forma mais facil...

Valeu pela dica.

O pessoal ta querendo matar umas focas usando struts, sabe se ele implementa algo relacionado a autenticação? ou algo relacionado a essas transações?

louds wrote:Eu faço isso porque é a forma mais facil...

Esse exemplo seu é algo parecido com isso:

e com os devidos, rollback e closes ?

louds, como fica a concorrência, neste caso?

daniel, a implementação usa uma ThreadLocal para manter o estado de cada thread, isso elimina problemas de concorrencia.

skill_ufmt, sim, bem parecido. A diferença é o local onde se inicia e termina a transação, no seu exemplo fica no meio do código de negocios, no meu fica em um servlet filter separado. A vantagem de fazer tudo de um lugar só é permitir compor código transacional sem se preocupar com criação espuria de múltiplas transações.

Se bem entedi, o modo do louds, poderia fazer assim que daria no mesmo:

Mas como o Daniel disse, como fica a concorrência neste caso? coloco syncronized no método?

Hummmm.. mto interessante. E eu sempre me perguntava como isso era feito.... hahahhahhahaaa

louds wrote:
skill_ufmt, sim, bem parecido. A diferença é o local onde se inicia e termina a transação, no seu exemplo fica no meio do código de negocios, no meu fica em um servlet filter separado. A vantagem de fazer tudo de um lugar só é permitir compor código transacional sem se preocupar com criação espuria de múltiplas transações.

ah ta, concordo, então estes dois exemplos que coloquei aqui, estão certos, só faltando mesmo refinar no quesito de favorecer composição.

Sim, nunca manipule a transação dentro de um DAO. Existem alguns muito poucos cenarios que justifica fazer isso.

louds wrote:daniel, a implementação usa uma ThreadLocal para manter o estado de cada thread, isso elimina problemas de concorrencia.

Poderia postar um código exemplo dessa sua Thread?
Você abre uma Thread para cada conexão? cada método? cada transação, jogando a conexão nessa thread?

skill_ufmt wrote:Poderia postar um código exemplo dessa sua Thread?
Você abre uma Thread para cada conexão? cada método? cada transação, jogando a conexão nessa thread?

Não... O problema de concorrencia é quando varias threads acessam o mesmo recurso, se eu criasse mais threads, só pioraria.

Em vez disso uso a class java.lang.ThreadLocal. Ela permite de forma facil guarda uma variavel que o valor depende da thread acessando.

louds wrote:Sim, nunca manipule a transação dentro de um DAO. Existem alguns muito poucos cenarios que justifica fazer isso.

vo usar um método do mister_m hehe
me diga um caso de uso exemplo, onde justifica este uso?

Lembrando que a equipe quer usar usar struts, esse controle de trheads teu, ficaria onde neste cenário? Action? uma clase para que as Action usem? no Tomcat?

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