Pourquoi changer de pool de connexion sous Tomcat et utiliser tomcat-jdbc ?

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 

Pourquoi changer de pool de connexion ?
Tomcat propose sur son site une explication détaillée sur les différences entre commons-dbcp et tomcat-jdbc-pool.

Je vais essayer de vous résumer les points principaux. Le principal problème du pool commons-dbcp est qu'il est mono-thread. Pour être thread-safe il doit verrouiller tout le pool, même pour une requête de validation. Si le la taille du pool est mal configurée vous pouvez vous retrouvez avec un deadlock. Dernièrement je suis tombé dans ce cas avec une simple requête de contrôle du pool de connexion (validationQuery) qui bloquait tout le reste. Cette limite peut être la raison de certains problèmes de performance. Ceci est d’autant plus vrai sur les machines d'aujourd'hui où le nombre de CPU ne fait qu'augmenter. Le pool commons-dbcp souffre aussi de la lourdeur de son code qui le rend difficilement modifiable.

Tomcat-jdbc-pool est un nouveau pool de connexions totalement intégré à Tomcat (librairie tomcat-jdbc.jar présente par défaut dans le répertoire lib de tomcat). Ce pool cherche à corriger les problématiques que je viens d'exposer en apportant d'autres fonctionnalités.

Par exemple si le pool est vide, et qu'un thread est en attente d'une connexion, nous n'avons pas forcément d'exception. En fonction de votre paramétrage (voir plus de précision dans le chapitre optimisation de la taille du pool de connexions) le thread peut être mis en attente et réveillé dès qu'une connexion est retournée au pool.

Je ne les citerai pas toutes les nouvelles caractéristiques mais en voici quelques unes

• meilleure performance 
• possibilité de configurer ces propres intercepteurs pour par exemple faire des statistiques sur les requêtes, tenter une nouvelle connexion en cas d’échec... 
• récupération d’une connexion en mode asynchrone. Vous poster une demande dans une file d’attente et vous recevrez une Future<Connection> 
• plus de possibilité de paramétrage dans la gestion des connexions (inactives, abandonnées...) 
• support XA 

Paramétrage d’une datasource dans Tomcat
Nous allons paramétrer une datasource commune à nos webapps dans le fichier [TOMCAT_HOME]/conf/server.xml dans la balise <GlobalNamingResources></GlobalNamingResources>.

Par exemple

<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"
/>