JDBC Driver Types & Architecture
The Data Access Handbook explains two major reasons a database driver can degrade the performance.
- The architecture of the driver is not optimal.
- The driver is not tunable. It does not have runtime performance tuning options that allow you to configure the driver for optimal performance. The type of options that we are talking about are ones that you can adjust to match your application and environment. For example, if your application retrieves large objects, look for a driver option that allows you to configure how much active memory the driver uses to cache a large object.
This post details on the different database driver architectures.
Four distinct architectures exist for database drivers: bridge, client-based, database wire protocol, and independent protocol. Choose a database driver that is implemented with an architecture that provides the best performance for your application.
Type 1 – Bridge Architecture
A bridge is a database driver that bridges between an existing database connectivity standard and a new one, as shown in figure.For example, when Sun Microsystems, Inc. released the JDBC specification, Sun wanted to encourage developers to use JDBC, but not many JDBC drivers were on the market at the time. However, hundreds of ODBC drivers to almost every data source were available, so Sun Microsystems, Inc. released a single JDBC/ODBC bridge that gave Java developers access to all the data sources that the ODBC drivers supported.
An implementation of the JDBC API translated the incoming JDBC calls to the appropriate ODBC calls using the JNI (Java Native Interface). The requests are then sent to the underlying ODBC driver (which at the time was just a shell over the database native client libraries). The bridge implementation shipped with the JDK so you only needed the ODBC drivers and native DB client libraries to get started.Unless no other solution meets the requirements of your database application, you should consider using a database driver with a more optimal architecture.
Following are the disadvantages of using bridges:
• Often they cannot fully implement a new standard because they are constrained by the definition of the alternate standard.
• They can pose security risks.
• Many implementations struggle to function optimally under high user counts.
Type 2 – Client Based Architecture
Client-based database drivers communicate with the database through the database’s client software, as shown in the figure. This software is the database vendor’s proprietary software, such as Oracle Net8 or OpenClient for Sybase
Following are the disadvantages of using client-based drivers:
• You must install, configure, and maintain database client software on every computer that needs database connectivity.
• You may have to install and support a different version of the client software for each version of the database system you are using.
• The database driver must be developed with the restrictions of the client software, which may be either functional or quality restrictions. For example, if your application is designed to run on a 64-bit Linux operating system, but the database vendor does not offer its database client software on that operating system, the database driver vendor cannot develop a 64-bit Linux driver.
The Oracle JDBC OCI drivers are Type 2 drivers that uses Java native methods to call the C entrypoints of the OCI library.
Type 3 – Two Tier Architecture
The database driver translates the standards-based API calls into a database-independent protocol, which is then translated to the database wire protocol by a server. This architecture has both a database driver client and server component, as shown in figure.
Typically, this type of architecture provides advanced security features such as the latest SSL encryption, access to a more varied set of data sources such as SQL to VSAM files, and centralized management and monitoring.
One main disadvantage exists for this type of driver: a client and server component must be installed, configured, and maintained.
Type 4 – Database Wire Protocol Architecture
Databases have a proprietary API that allows other software components to communicate with them. In a client-based architecture, the client software makes the wire protocol calls to the database. In a database wire protocol architecture, the database drivers generate the required wire protocol calls, thereby communicating directly with the database.
The benefits of choosing a database driver that has a database wire protocol architecture are many.
1. The database driver can be installed with your database application and can immediately connect to the database without configuring other software.
2. You do not have to install, configure, and maintain database client software.
3. Performance is improved because a database wire protocol driver does both of the following:
• Decreases latency by eliminating the processing required in the client software and the extra network traffic caused by the client software.
• Reduces network bandwidth requirements from extra transmissions. That is, database wire protocol drivers can optimize network traffic because they can control interaction with TCP.
4. Regarding Java and ADO.NET, another important advantage exists when you use a database wire protocol driver/provider: The driver/provider does not have to make calls to the client software. For Java, this means the driver can use Pure Java code and not make calls to the native libraries. The Pure Java standard is a set of programs, rules, and certifications used in the design process to ensure that Java executables live up to the WORA (write once, run always) principles. A Pure Java program relies only on the Java Language specifications. Using native methods in a Java program means that you lose the benefits of the Java runtime, such as security, platform independence, garbage collection, and easy class loading. Specific external functionality is provided by the Java core APIs, such as JDBC.
The JDBC Thin driver is a 100% Java Type 4 driver. It connects directly to Oracle via Java sockets without the need for a JDBC-specific middle tier. The JDBC Thin driver can only connect to a database if a TNS Listener is up and listening on TCP/IP sockets.