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.
Commenti recenti