Les drivers qui permettent à l’API JDBC d’interagir avec une base de données relèvent de l’une des quatre catégories suivantes:

• JDBC-ODBC Bridge
• Native-API/partly Java driver
• Net-protocol/all-Java driver
• Native-protocol/all-Java driver
 

Les drivers relevant de la première catégorie transitent par une passerelle ODBC avant d’acheminer les appels de l’API JDBC vers le gestionnaire de base de données. Parce qu’ODBC est écrit en C, ils doivent effectuer des conversions qui sont très coûteuses pour les performances. Notons par ailleurs que ces drivers doivent nécessairement être installés sur le poste du client pour qu’il puisse interagir avec la base de données (or sur le réseau Internet les développeurs n’ont aucun contrôle sur les drivers et les plug-in installés sur les postes des clients).

Figure 53: JDBC-ODBC bridge [220]
 

Les drivers de la deuxième catégorie convertissent les appels de l’API JDBC via une interface native (JNI) qui est supportée par le gestionnaire de base de données. Ils sont plus performants comparativement aux drivers de la première catégorie mais pour qu’ils fonctionnent correctement une partie de leur byte code doit être installée sur le poste du client (d’où le nom partly Java driver).
 

Figure 54: Native-API/ partly Java driver

Les drivers de la troisième catégorie sont entièrement écrits en Java et s’intègrent dans une architecture à trois tiers. Ils envoient les appels de l’API JDBC à un middleware via un protocole indépendant du gestionnaire de base de données. A réception de ces appels le middleware les convertit dans un protocole spécifique au gestionnaire de base de données. Les drivers de la catégorie 3 offrent un meilleur niveau de performance que les drivers de la catégorie 2 parce qu’ils supportent des techniques d’optimisation comme la gestion du cache et le load balancing[221]. A noter qu’avec cette catégorie, le client n’a pas besoin d’installer le driver pour pouvoir interagir avec la base de données.

Figure 55: Net-protocol/all-Java driver

A l’instar des drivers de la catégorie 3, les drivers de la catégorie 4 sont entièrement écrits en Java. Leur particularité c’est qu’ils reconvertissent les appels de l’API JDBC directement dans le protocole spécifique de la base de données. Pour interagir avec MySQL via JDBC, c’est cette catégorie de drivers qui offre le meilleur niveau de performance.

Figure 56: Native-protocol/all-Java driver

Cela dit, dans les tests de performance effectués par Ziff Davis Media Inc, c’est avec le driver Connector J [222] que MySql s’est qualifié au premier rang en ce qui concerne le débit et le temps de réponse (cf. figure 57). Notons par ailleurs que les versions récentes de ce driver sont 50 à 100 fois plus rapides que les versions initiales. De plus elles supportent le mode streaming qui permet aux requêtes de renvoyer un nombre très important d’enregistrements sans consommer excessivement la mémoire tampon (d’après le site www.mysql.com le driver est capable de renvoyer jusqu'à 2 gigabits d’enregistrements).

Figure 57: Database benchmark/ Ziff Davis Media Inc [223]

Sources:

[220] Source: Nitin Nanda, Learn how to deploy, use, and benchmark JDBC driver types 1, 2, 3, and 4, http://www.javaworld.com/javaworld/jw-07-2000/jw-0707-jdbc.html
[221] Technique consistant à partager et équilibrer une charge sur plusieurs serveurs.
[222] Nous rappelons que Connector J fait partie des drivers de la catégorie 4.
[223] Source: Eweek, Database benchmarking, http://www.eweek.com