Newsgroup: it.comp.java
Titolo: autocommit ResultSet e Connection

Premetto che sono un neofita del Java, vengo da un altro linguaggio di
programmazione (Delphi).
Ho il seguente scenario:
- Database Firebird con una tabella da 23 milioni di righe
- Una Connection
- Un ResultSet rs con SELECT campo1, campo2 FROM tabella
- Un ciclo while (rs.next)
- Per ogni riga della select devo fare un UPDATE tabella
Ora se faccio autocommit(false) ed eseguo il programma facendo commit
SOLO alla fine tutto ok, ma se nel fare UPDATE faccio anche commit, il
programma chiude la connessione anche al ResultSet.
Ho letto che questo è il comportamento standard di JDBC, mi chiedevo se
esiste un pattern o simile per risolvere il mio problema.
Grazie e chi mi vorrà aiutare.
Max

Max wrote:
 > - Per ogni riga della select devo fare un UPDATE tabella
La butto li': "Select For Update" ?

 La butto li': "Select For Update" ?
Non è implementato in Firebird..
Stavo leggendo che esiste anche una classe ConnectioPool, potrebbe forse
risolvere il mio problema ?
Max

 risolvere il mio problema ?
No. La connection pool e' un'insieme di connessioni. Dato che crearne 
nuove e' piuttosto dispendioso, queste non vengono distrutte ma 
mantenute in una pool e "pescate" quando servono.
Quel che non capisco e' perche' vuoi fare degli update mentre scorri un 
resultset. Non puoi farlo in due "passi" ma all'interno della medesima 
transazione ? E perche' devi fare un commit mentre scorri il resultset ?
E fare gli update usando un'altra connessione ?

 E fare gli update usando un'altra connessione ?
La tabella è di 23 milioni di record se apro il resultset per fare gli
update ho visto che fetcha tutti i record provocando un OutOfMemory,
quindi l'ho impostato in sola lettura (ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY) ma forse ho sbagliato io ad impostarlo.
Comunque era un programma usa&getta l'ho fatto tanto per impratichirmi
con il linguaggio, ho fatto commit solo alla fine; ma il mio dubbio rimane.
In genere come si fa in un programma desktop a fare la commit senza che
poi si chiudano i vari resultset aggancianti alla stessa connection ?
Cioè qual'è il modus operandi, il model, ecc che viene adottato nello
sviluppo di un programma desktop ?
Grazie ancora per la tua disponibilità
Max

 sviluppo di un programma desktop ?
Chiedi alla persona sbagliata: Nella mia esperienza di programmi desktop 
ho sempre avuto "dietro" un application server oppure un OR Mapping 
(Hibernate).

 (Hibernate).
Mi spieghi meglio questo concetto, per me è del tutto sconosciuto.
Grazie
Max


I progetti desktop (O anche Web) per i quali ho lavorato non andavano 
direttamente a leggere/scrivere dal database tramite SQL, ma delegavano 
la persistenza dei dati a un Application Server (EJB) come per esempio 
Borland Applcation Server ('na chiavica :)), BEA o JBoss.
Quelle poche volte che non era necessario un Application Server, la 
gestione della persistenza veniva affidata ad un OR Mapping tool 
(Hibernate, Castor (Chiavica2 :)), ...) il quale maschera la 
complessita' dell'accesso ad un database (Query SQL) offrendoti degli 
oggetti (Java Beans) che possono essere direttamente letti/scritti dal 
database invocandone dei metodi. Per esempio qualcosa del tipo
   User user = new User("giambo");
   user.getId(); // ritorna null
   user.saveOrUpdate();
   user.getId(); // ritorna la sua primary key
   Query q = new Query("from User as u where u.status = ?);
   q.setValue(0, Status.OK);
   List okUsers = q.execute(); // tutti gli utenti con stato "OK"
Sto diventando prolisso, ti rimando alla documentazione di Hibernate o 
al tutorial sugli EJB della SUN per maggiori informazioni ;) !

 al tutorial sugli EJB della SUN per maggiori informazioni ;) !
Non stai diventando prolisso, bensi' molto gentile :-)
Ti ringrazio tanto, mi togli una curiosità, come mai giambo ?
Altre due lettere infondo e diventa il mio cognome !
Max

 Altre due lettere infondo e diventa il mio cognome !
Altre 4 lettere e diventa il mio di cognome ;)

 esiste un pattern o simile per risolvere il mio problema.
il resultset è un oggetto connesso, sostanzialmente un cursore. quindi 
nel momento in cui esegui una commit nella stessa connessione lo invalidi.
oddio, non è sempre esattamente così, dipende dal dbms e da come 
gestisce i cursori, tuttavia questa non è in generale una buona pratica. 
   persino oracle quando apre un cursore si fa uno snapshot dei dati ma 
se tu questi dati glie li modifichi sotto il naso a un certo punto ti 
manda un errore.
la soluzione? usare gli strumenti di persistenza che anche per questo (e 
non solo) son tanto comodi... :-)

 
Mi dici quali ?
Grazie
Max

Max ha scritto:

hibernate.