Problema: si scopre che un determinato server database (in questo caso Oracle) è bombardato dalle negoziazioni di connessione da parte di Mirthconnect. Questo provoca una degradazione delle prestazioni del DBMS come per una sorta di attacco DOS.
Generalmente una connessione viene aperta, viene svolta una attività, e viene poi chiusa. Risulta spesso che il tempo di utilizzo del database in questo ciclo sia per una minima parte composto dal tempo di esecuzione dell’istruzione PL/SQL e invece per la maggior parte dal tempo di negoziazione tra il listener e il database server.
Se gli accessi sono molto frequenti, è preferibile tenere la connessione aperta e lanciare più attività, utilizzando una connessione da un pool di connessioni persistenti.
Una soluzione è quella di far aprire la connessione al db non dall’interno del componente JavaScript che ne ha bisogno ma dallo script di deploy:
In questo modo abbiamo la possibilità di avere una connessione persistente salvata nella mappa globale (globalChannelMap, accessibile da tutti i canali quindi) e fare riferimento ogni volta a questa evitando di invocare il metodo DatabaseConnectionFactory.createDatabaseConnection() che provocherebbe la negoziazione di una nuova connessione.
2 commenti
Il problema di questa soluzione è che se per caso la connessione con il DB cade, non ti funziona più nulla.
Quindi la risolvi solo mettendo una function nel deploy script questa la memorizzi in una global channel map,
come parametri in entrata gli passi la stringa di connessione e se vuoi le credenziali e gli fai tornare la connessione.
Nel source lanci una query semplice per esempio SELECT 1; se torna errore chiami la function e riapri la connessione.
Autore
Ciao!
Sì, hai ragione.
Nei canali di produzione infatti utilizzo da molto tempo il meccanismo di connection pool.
Grazie del tuo contributo!