Tomcat-jdbc-pool est un nouveau pool de connexion introduit à partir de Tomcat 7 en remplacement du pool de connexion commons-pool généralement utilisé sous les versions antérieures de Tomcat. Toutes les options de configuration ont été reprises et d'autres ont été rajoutées ce qui vous permettra facilement de migrer de commons-pool à tomcat-jdbc-pool.
Je vous propose une série d'articles sur le sujet
- Pourquoi changer de pool de connexion et utiliser tomcat-jdbc ?
- Optimisation de la taille du pool de connexion tomcat-jdbc
- Pool tomcat-jdbc : gérer les problèmes d'accès à la datasource
- Pool tomcat-jdbc : gérer les timeout sur les requêtes
- Les intercepteurs introduits avec tomcat-jdbc
Intercepteurs
Une grande nouveauté de tomcat-jdbc est la mise en place d'un mécanisme d'intercepteurs vous permettant de mettre en place votre propre procédure afin d'activer, désactiver ou modifier des fonctionnalités du pool de connexion.
Plusieurs intercepteurs sont fournis par Tomcat. En voici une rapide liste
- ConnectionState : Met en cache les propriétés autoCommit, readOnly, transationIsolation pour éviter de les redemander à la base de données à chaque fois que l'application en a besoin.
- StatementFinalizer : StatementFinalizer surveille les différentes déclarations faites à l'aide des méthodes createStatement, prepareStatement ou prepareCall afin de fermer les connexions si ce n'est pas fait par l'application. Cet intercepteur peut vous rendre service quand le code de l'application n'est pas accessible (progiciel ou même application patrimoniale)
- SlowQueryReport et SlowQueryReportJmx : Ces deux intercepteurs (le deuxième étend le premier) vérifient le temps d'exécution d'une requête afin de loguer les requêtes trop longues (SlowQueryReport) et notifier via JMX ces requêtes (SlowQueryReportJmx). Cet intercepteur fournit un mécanisme simple de supervision des requêtes trop longues ne demandant qu'un redémarrage du serveur.
- ResetAbandonedTimer : Cet intercepteur est un complément de la propriété removeAbandoned. Le timer lié à removeAbandoned démarre lorsqu'une connexion est récupérée. Si votre transaction est complexe (exécution de plusieurs requêtes dans le cas d'un batch par exemple), votre connexion peut être marquée comme abandonnée alors qu'il ne le faudrait pas. L'intercepteur réinitialise le timer à chaque requête ce qui vous permet d'être beaucoup plus fin dans la gestion des connexions abandonnées.
jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;StatementFinalizer(useEquals=true)"
Vous pouvez également développer vos propres intercepteurs.
En conclusion
Je pense qu'il est intéressant voir souhaitable de passer au pool de connexion intégré à Tomcat pour une application en production. Si je reprends les différents paramètres exposés dans les différents chapitre ma configuration serait la suivante
<Resource name="jdbc/myDataSource" type="javax.sql.DataSource" factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" auth="Container" username="MYUSER" password="MYPASSWORD" driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@localhost:1521:ORA" initialSize="10" maxActive="100" maxIdle="50" minIdle="10" timeBetweenEvictionRunsMillis="30000" minEvictableIdleTimeMillis="60000" suspectTimeout="60" removeAbandonedTimeout="180" removeAbandoned="true" logAbandoned="true" testOnBorrow="true" validationQuery="SELECT 1 FROM DUAL" validatorClassName="com.ehret.tomcat.ConnectionValidator" validationInterval="30000" jdbcInterceptors="ConnectionState;StatementFinalizer;" />
Référence et autres liens sur le sujet
Vous pouvez lire les principaux articles que j'ai utilisés pour cet article
- la page Tomcat liée au pool
- l’article d’Arnaud Cogoluègnes qui indique comment intégré le pool pour des application Maven/Spring
- deux articles du site tomcatexpert sur les performances, un autre sur le paramétrage
Aucun commentaire:
Enregistrer un commentaire
Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.