Newsgroup: it.comp.java
Titolo: JDBC Transaction e architettura

Ciao a tutti,
mi chiamo Andrea, lurker del NG, ho partecipato saltuariamente a 
qualche discussione.
Protagonista del mio problema è la web application che sto sviluppando: 
architettura a 3 livelli, MVC per lo più rispettato e NERVATE SULLA 
SCHIENA per non aver utilizzato OJB! :-(
Lo strato DAO dell'applicazione è composto da 'n' classi contenenti 
metodi che interrogano il database e restituiscono oggetti che, nella 
maggior parte dei casi, mappano 1:1 le tabelle fisiche. (altra frustata 
sulla schiena, ho riscritto in parte OJB!)
Ogni metodo richiede una Connection al pool, ottiene un ResultSet, lo 
passa ad un metodo statico che ne estrae e manipola il contenuto, 
ritorna l'oggetto descritto qualche riga sopra, "finally" chiude 
Statement, Connection, ecc...
In questa fase di sviluppo avrei la necessità di chiamare all'interno 
di una transaction alcuni dei metodi già scritti, onde evitare di 
ripetere il medesimo codice...problema: come già scritto, ogni singolo 
metodo richiede e chiude una sua Connection, ma essendo già all'interno 
di una transaction ciò che ottengo è circa 80cm di stacktrace! :-(
E' da un po' di tempo che cerco la soluzione più pulita possibile, ma i 
risultati sono scarsi; la situazione non è bloccante ai fini del 
corretto funzionamento dell'applicazione, ma mi piacerebbe un consiglio 
da voi esperti su come poter uscire a testa alta da questa situazione.
Nel caso sia utile, la webapp gira su Tomcat 5 e MSSQL.
Grazie a tutti per la collaborazione.
--
Elimina tutti gli MP3 per rispondermi
 
Inviato da 
www.mynewsgate.net

> Ciao a tutti,
Il problema architetturale da te posto e' canonico.
Nel senso che e' molto frequente.
Non esiste chiaramente una soluzione
come tu setsso mi pare hai capito quando parli di testa alta.
Il fatto di aprire e chiudele la connection
ha il vantaggio di creare delle classi
semplici da usare e soprattutto
se siete + di 1 a lavorare sul
progetto evita che qualcuno lasci
aperta la Connection, cosa parecchio fastidiosa
D'altra parte e' limitante perche'
se usi 4 metodi in serie dello stesso DAO
ti trovi ad aprire e chiudere 4 volte del tutto aggrattis.
ecco allora le soluzioni miste.
Alcuni dei Dao possono lasciare aperta la Connection
e si pongono chiaramente in autocommit(false)
a questo punto devi chiudere tu
e attento che devi verificare di chiudere
qualsiasi ramo dell'algoritmo generale inforchi
per esmmpio nei rami Exception
che a questo punto devi per forza intercettare e al limite
retroware
Viene voglia di fare una classe Manager che da la connection a tutti i
DAO e si preoccupa di fare tutte queste operazioni,
oppure fare estendere i DAO da un base DAO
ma ho paura che ti ritrovi
a scrivere quello che ti manca di OJB
o Hibernate
pensa che dopo 2 o 3 anni di rifiuto
degli Entity EJB sto pian piano ripigliandoli.
Java e' come D&G e ogni 2 o 3 anni si cambia stile he he
   Good Work
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

> Nel caso sia utile, la webapp gira su Tomcat 5 e MSSQL.
Usare un pool di connessioni ?
Mi sembra la soluzione migliore e Tomcat la gestisce nativamente.
Ciao,
CC

 Mi sembra la soluzione migliore e Tomcat la gestisce nativamente.
Mmhh...scusa, in che senso le gestisce nativamente?
Noi utilizziamo DBCP e la connesssione al DB viene inizializzata da una 
servlet...
La soluzione da te proposta mi vincolerebbe al servlet container, sbaglio?
Grazie e ciao!


 Java e' come D&G e ogni 2 o 3 anni si cambia stile he he
LOL, sono quasi al secondo anno di utilizzo ed è uscito il JDK 1.5 con 
tutte le sue novità: hai ragione! :-))
Grazie di tutto!


 interfacce con codice OJBImpl.
Perche' no ?
il pool, se ancora non lo usi,
ottimizza la gestione delle Connection
ma non ti risolve il problema architetturale.
Prova la tua strada, se la fai bene non dovrebbe darti fastidi,
visto che lasci le chiusure delle connection nelle
finally del DAO senza logica
e le Operations stanno nei metodi di logica che a questo punto possono
essere chiamati in serie o singolarmente.
        cya, Nicola


 essere chiamati in serie o singolarmente.
Si, per ora effettivamente con log4j teniamo sotto controllo le active 
connections e non ci sono problemi...a parte in un caso, nel quale avevamo 
scordato un blocco finally: diciamo che il pool si gonfiava abbastanza. ;-P
Questa sera inizio il refactoring dei metodi, a breve mi farò risentire per 
comunicarvi l'esito di questa soluzione.
Grazie e ciao!


 La soluzione da te proposta mi vincolerebbe al servlet container, sbaglio?
Si.
Ciao,
CC