Newsgroup: it.comp.java
Titolo: pool di connessioni...quanto tempo possono rimanere attive al massimo?

ciao a tutti,
sto progettando un applicazione jsp-servlet che sfrutta un database
MySql...devo fare in modo che piu utenti possano connettersi
contemporaneamente, e quindi poter scrivere, leggere nel database.
Per fare questo mi è stato consigliato l'uso del pool di connessioni
(grazie millle) che ho trovato molto utile...ora vorrei sapere...visto
che in questo pool si usano un certo numero di connessioni sempre
attive, che man mano vengono rilasciate da un utente e passate ad un
altro...senza mai chiuderle...c'e' un tempo massimo  di durata di
queste connessioni?
Cioe' una connessione puo rimanere aperta indefinitamente oppure ha un
tempo massimo oltre il quale deve essere chiusa? 
Altra domanda...se dalla connessione creo uno statement, quasto
statement puo rimanere aperto indefinitamente, o anche qui c'e' un
tempo massimo prima di chiuderlo?
Questo perche alla partenza del webserver+tomcat io farei partire il
pool di connessioni, che quindi mi rimarrebbero aperte finche non
viene chiuso il server...e' un dubbio che ho...spero risolvibile ;))
grazie
____________________________________________________________________________________
email : 
filip...@libero.it

 c'e' un tempo massimo  di durata di queste connessioni?
In generale no, ma dipende dal database. Di solito oltre un certo
tempo limite in cui la connessione non viene usata (aka: nessuna
richiesta viene inoltrata al database tramite quella connessione),
il database chiude la connessione perche' ipotizza che il client che
la usava sia "morto".
Pero' spero che tu verifichi che la connessione sia ancora "viva"
prima di usarla...
Davide
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Dipende dal pool che stai usando: qual'e'?
Personalmente quello che avevo fatto io dopo un po' le chiudeva, e ne teneva un tot aperte
gestendone dinamicamente il numero in base al numero di richieste.
Ciao,
    Bruno,
---
| Bruno Bossola
| A Java Software Engineer :-)
| 
http://members.xoom.it/bbruno
| 
http://digilander.iol.it/bbossola


sto usando il pool che ho trovato come esempio su mokabyte,
modificandolo un po
li per esempio inizializzava il pool aprendo un tot di connessioni,
rilasciava una connessione quando un utente finiva le sue
operazioni...ma non la chiudeva, bensi la rendeva disponibile a un
altro utente...
cioe ogni volta che un utente prendeva una connessione, la rilasciava
ponendo un campo flag a true alla fine delle operazioni (metodo
destroy della servlet...) ma senza chiudere la connessione.
cmq quello che faccio io, e' aprire un tot di connesioni, lasciarle
sempre aperte finche spingendo un bottone di una pagina jsp si
"spegne" il server con tutte le connessioni...
potrebbe succedere che ho 10 connessioni aperte, e 2 utenti connessi
che usano sempre le prime 2 ad esempio...le altre 8 se rimangono
aperte e mai utilizzate per ore?
boh senno non so proprio come fare...
se io ad esempio volessi avere (per ragioni che sto a spiegare) uno
statement sempre aperto...avro dei problemi? ad esempio...supponendo
non sia mai usato...potrebbe anche capitare...
grazie delle risposte
____________________________________________________________________________________
email : 
filip...@libero.it

 wrote in message
news:3c6b7fd8...@powernews.libero.it...
Personalmente ho realizzazato un pool che tiene aperte le connessioni
indefinitivamante per tutta la vita della servlet. Verifica che il
database non chiuda lui le connessioni che risultano da troppo tempo
inattive. Se è così ti troveresti dei nullPointerException tra i piedi
senza sapere il perchè.
Ciao,
Mauro


Ciao,
solo una considerazione, spero che non la interpretiate come polemica:
fare un pool è semplice? E quanto è critico all'interno di un progetto? E
quanto lo diventa se l'applicativo è multi utente e magari finisce su
internet?
Questo è quanto ho visto l'ultima volta che ho avuto a che fare con un pool
di connessioni "artigianale" per implementare un'attesa con timeout quando
tutte le connessioni sono occupate :
      int
        times = timeout * 10;
      long
        base = 0L,
        now  = 0L;
      for (int i = 0; i < times && (m_conn = allocate()) == null; i++)
      {
        base = System.currentTimeMillis();
        now  = base;
        while (now - base < 100L)
          now = System.currentTimeMillis();
      }
(Risultato, CPU al 70% o giù di lì... immaginate cosa succede se 10 utenti
eseguono questo codice. Ora non ci crederete ma questo codice è in
produzione e viene anche considerato un pool "affidabile")
Da allora spero sempre di non vedere pool "fatti in casa". Finora ne ho
visti due, l'altro funzionava.
Ma è un po' come volersi fare il webserver o il database engine quando
l'utente ti chiede di fare un applicativo gestionale. Non ci sarebbe nulla
di male, se per fare un pool si schedulasse minimo un mese di lavoro, ma c'è
chi si fa un pool di connessioni in mezza giornata, e non è sempre una bella
idea.
Io comunque non mi affiderei tranquillamente al codice esposto in una
rivista per motivi "didattici". La stessa obiezione potrebbe essere mossa ai
pool disponibili gratuitamente, ma in genere penso che se qualcuno mette a
disposizione il suo codice gratuitamente si senta comunque responsabile di
quello che ha fatto e lo distribuisca solo se è un lavoro ben fatto.
Pool opensource gratis:
PoolMan: 
http://www.codestudio.com/
DbConnectionBroker: 
http://www.javaexchange.com/
Ora sto usando Minerva di 
jboss.org
, ma non ho trovato il link, di sicuro si
scarica da 
www.jboss.org
 girando un po' nel repository cvs.
Se un pool è ben fatto può essere cambiato (altra caratteristica di cui
molti pool artigianali sono in difetto, visto che essendo fatti per esigenze
di progetto non è previsto che siano intercambiabili se danno problemi).
Ciao!
Luigi.

Forse un mese è troppo, ma non ho ancora fatto "il mio pool" :)


Si, lo statement e' legato alla connessione: chiusa quella, chiuso lo statement.



Yup!
Ciao,
    Bruno.


 Si, lo statement e' legato alla connessione: chiusa quella, chiuso lo statement.
hmmm.... fidarsi è bene, non fidarsi è meglio.
Un'applicazione che girava su Websphere 3.02, a causa di un qualche bug 
implementativo del connection pool dello stesso, non chiudeva i 
resultset alla chiusura degli statement..... risultato: ricercare a 
manina tutti i punti in cui il programmatore distratto aveva dimenticato 
di chiudere i resultset prima degli statement..... ;(
-- 
Kali
"Therefore... There are patterns everywhere in nature"


Credevo che la mia risposta fosse chiara nel suo contesto: e' chiaro che se prendi il
pezzo che decidi tu estraendolo dal contesto, il senso cambia (come fanno certi
giornalisti, per intenderci :-D)
Nel suo contesto, la mia risposta e': 
"si, avrai dei problemi" 
e non
"si, vai pure tranquillo che se chiudi la connessione verra' chiuso anche lo statement"
In generale, fai bene a puntualizzare: solo non mettere in mezzo gente che non c'entra.
Ciao,
    Bruno.


 In generale, fai bene a puntualizzare: solo non mettere in mezzo gente che non c'entra.
avevo letto molto bene il tuo post, e sapevo che avresti risposto cosě ;PP
il mio piu' che altro č stato uno sfogo contro il tempo perso a causa di 
aibiem ;))
chiedo scusa, avrei dovuto cambiare il subject o specificare meglio :)


 pool gia ce l'ha?
Verissimo! Soprattutto perché in questo modo il pool potrebbe essere
veramente ottimizzato per lo specifico db, che potrebbe avere politiche di
gestione particolari per le connessioni, visto che si tratta di un punto
critico per quanto riguarda le performance di un database.
A riproposito di PoolMan, oltre a fare da connection pool per i database,
può fare da connection pool per qualsiasi cosa... può fare anche pooling di
istanze di oggetti, di thread e chi più ne ha più ne metta. Quì da noi si
sta cominciando ad usare e pare molto bello.

Di norma io chiudo statement e connessione. il resultset, da specifiche
dovrebbe chiudersi con lo statement (e viceversa).


Si, il pooling di thread e' particolarmente importante, specie se si considerano
applicazioni in cui ci sia la necessita' di gestire code di eventi e sottoscrittori in
modo molto dinamico. 
Beh, a saperlo! Io un pool di thread me lo feci da solo un po' di anni fa. 



Se hai usato i thin driver di Oracle sai che non e' cosi :-D, vero? La mia posizione e'
sempre la stessa, chiudere tutto quello che hai aperto (quando e' possibile) con un bel
blocco try / finally.
