JAVA: Connessione DB

[sarcaz]

Sarebbe interessante in ambiente JAVA+Tomcat poter lasciar gestire le connessioni al DB a Tomcat.
Come abbiamo visto con Matteo Sirri in assistenza, siamo riusciti ad ottenere questo personalizzando la funzione CloseDBConnections, disattivandola, però avere un parametro di configurazione eviterebbe il dover verticalizzare un file di template di INDE.
Pensate che gestire i webservice con molti accessi concorrenziali con connessione diretta al DB invece che tramite il ConnectionPool di Tomcat porta ad un carico dell'applicazione 600-700 volte superiore.

[lucabaldini]

Non mi è chiara la tua richiesta.

Le applicazioni web e web service prodotti con In.de hanno un proprio connection pool che è molto efficiente e riutilizza le connessioni in automatico.

Ogni volta che una sessione o richiesta ha necessità di collegarsi al DB viene richiesta al nostro connection pool se esiste una connessione non chiusa... se esiste viene utilizzata altrimenti ne viene creata una nuova.
Alla fine di ogni richiesta la connessione viene rimessa nel pool per poterla rendere disponibile ad altre richieste.
Se una connessione non viene utilizzata per più di 15 minuti viene chiusa ed eliminata dal pool.

Cosa manca?

[sarcaz]

Credo allora che il connection pool di inde non funzioni correttamente con i WS, in pratica se io ho un metodo pubblico all'interno di un WS e questo viene eseguito sequenzialmente 300 volte mi ritrovo 50-60 connesisoni al DB aperte...
Tale caso non può essere replicato con un loop che esegue tale procedura ma ti assicuro che in un ambiente di produzione dove ho i WS pubblici utilizzati da un sito Web on circa 1500 visitatori giornalieri se uso la connessione di INDE ho circa 300 connessioni al DB aperte , se utilizzo il connection pool di Tomcat non supero le 10 connessioni poichè le richieste concorrenziali non sono più di 10-15....
Il problema mi si è presentato solo con i WS e non con le applicazioni.

Avevo richiesto tale modifica per evitare di modificare la procedura:
public void CloseDBConnections()
{
}
all'interno del file _ICD_VBP_FORM.java
spero di essermi spiegato...

[lucabaldini]

Credo sia necessario guardare meglio il caso.
Il connection pool di In.de non chiude mai le connessioni ma le "rilascia" nel pool.
Una connessione viene ripresa dal pool solo se questa utilizza lo stesso username, password e connection string.

Bisognerebbe controllare il LOG di tomcat dell'applicazione fatta con In.de per capire perché viene creata una nuova connessione.

[sarcaz]

nei link sotto trovi i log
prima della modifica con connessione gestita da inde (un estratto di 2 ore, il giornaliero sono quasi 200mb):
http://www.initzero.it/tmp/catalina20140117.out

il log di oggi usando il connection pool di tomcat:
http://www.initzero.it/tmp/catalina20140120.out

[lucabaldini]

Da quel che vedo sembra che la connessione non venga mai "chiusa" (ovvero rilasciata nel pool).
Bisognerebbe guardare il tuo progetto per capire perché il tuo WS non rilascia le connessioni al pool.
Senza vedere il progetto non capisco cosa succeda... In teoria dovrebbe funzionare così: l'apertura della connessione è automatica e viene fatta appena una query viene eseguita. L'apertura contatta il nostro pool e cerca una connessione da utilizzare. Se non c'è ne viene creata una nuova e fornita al WS. Il WS la usa e quando occorre (poi ti spiego), la rilascia al pool ancora aperta. A questo punto, se un nuovo metodo vuole fare una query chiede al pool che fornisce quella di prima che viene riutilizzata, poi ri-lasciata al pool.

Dal tuo log sembra che le connessioni non vengano mai chiuse e questo è il problema.

In una applicazione web tutte le connessioni ai DB vengono automaticamente chiuse alla fine di ogni richiesta del browser. Per i WS non è così semplice, perché non c'è un "fine richiesta del browser". L'entry point di un WS, infatti, è una chiamata ad un metodo pubblico dell'unica classe pubblica del WS. Quando esci da quel metodo pubblico, In.de chiude tutte le connessioni aperte automaticamente (puoi verificare nel codice di un qualunque metodo pubblico della classe pubblica del WS).

Ora, se per un qualunque motivo, il codice segue un percorso che non chiude le connessioni al DB, allora succede quel che dici... le connessioni non vengono chiuse (che vuol dire che non vengono rilasciate al pool ma ne vengono aperte sempre delle nuove) può succedere quel che descrivi...

Quindi occorrerebbe guardare il tuo WS (in particolare tutti i metodi pubblici della classe pubblica) e capire se c'è un percorso di codice che non termina con una CloseDBConnections che tu hai personalizzato.

Questo dovrebbe essere il motivo.

[sarcaz]

Ciao Luca, il progetto è abbastanza complesso... ci sono circa 100 metodi pubblici... se vuoi posso inviarvelo oppure programmare un'assistenza, ma comunque da quello che ho potuto vedere, la closedbconnections avviene sempre in corrispondenza del return della funzione e noi usiamo solo funzioni.
questa è una procedura di esempio...

public String Getconfig () throws RemoteException
{
StringBuffer SQL = new StringBuffer();
int TransCount = 0;
int ReturnStatus = 0;
IDCachedRowSet QV;
DbEcom DbEcomObject = ((Webcommerce)MainFrm).DbEcomObject;

try
{
TransCount = 0;
//
// Getconfig Body
// Corpo Procedura
//
IDCachedRowSet v_REC = null;
v_REC = (IDCachedRowSet)new IDCachedRowSet();
SQL = new StringBuffer();
SQL.append("select ");
SQL.append(" A.MAILSISTCONF as MAILSISTCONF, ");
SQL.append(" A.SMTPSERVCONF as SMTPSERVCONF, ");
SQL.append(" A.SMTPUSERCONF as SMTPUSERCONF, ");
SQL.append(" A.SMTPPASSCONF as SMTPPASSCONF ");
SQL.append("from ");
SQL.append(" CONFIG A ");
v_REC = DbEcomObject.DBO().OpenRS(SQL);
if (!v_REC.EOF()) v_REC.MoveNext();
MainFrm.CloseDBConnections();
return (new IDVariant(v_REC.SaveToXML())).stringValue();
}
catch (Exception _e)
{
MainFrm.CloseDBConnections();
throw new RemoteException("Getconfig - "+_e.getMessage(),_e);
}
}

[lucabaldini]

Infatti non dovrebbe succedere che si esca da un metodo senza chiamare la CloseDBConnections... ma se dovesse succedere quella connessione verrebbe "persa" e mai riutilizzata...

L'unica soluzione che mi viene in mente è guardare tutti i metodi pubblici e vedere, se per un qualunque motivo, il codice potrebbe uscire dalla funzione/procedura senza chiamare la CloseDBConnections.

Se tutto è a posto occorrerebbe controllare perché le connessioni nel tuo caso non vengono "rilasciate" nel pool... io ho provato nel mio progetto e funziona come mi aspetto. Apre una connessione e riutilizza sempre quella.

Ma il tuo LOG parla chiaro: vengono aperte sempre nuove connessioni, quindi sospetto che non vengano mai chiuse.