JDBC Type 5 Drivers Needed to Overcome Type 4 Limitations
The Java Database Connectivity (JDBC) API is the data connectivity standard for industrial-strength, data-driven Java applications, and for nearly all purposes, native protocol (Type 4) drivers provide the best JDBC architecture. However, in the 10-plus years since Type 4 was introduced, some important and far-reaching innovations and trends have taken place in the Java ecosystem. These advancements have pushed Type 4 drivers beyond their limits in today's data centers.
Any JDBC drivers that are fundamentally based on the Type 4 architecture yet are designed to address all or most of these limitations represent a drastic departure from the norm. In fact, such drivers could be classified as an entirely new type. Call them what you will, but for the purposes of this discussion, they are "Type 5."
Not all developers truly understand the role JDBC middleware plays in application-to-data operations, beyond simply enabling connectivity. In fact, with the increased abstraction of object modeling and higher-level applications, many a developer views JDBC drivers as vital but "dumb" pipes rather than critical cogs that not only drive the success of an application stack but also enhance it.
For this reason, some in the developer community may take a "so-what?" attitude toward the notion of a JDBC Type 5 driver. They may even reject the whole notion of a data connectivity driver as a component where innovations such as application failover for high availability ought to take place. Such innovations, they could reason, are more appropriately handled at the higher application level. This reasoning, however, is very debatable.
The Limits of Type 4
Among developers who are knowledgeable about the behind-the-scenes workings of middleware data connectivity using JDBC drivers, the limitations of a Type 4 driver are generally undisputable. These include:
- The need to write and maintain code specific to each supported data source. Even with modern framework-based object-relational mapping (ORM) models, JDBC Type 4 drivers typically require the use of proprietary code to support variant database features such as BLOBs and CLOBs, high availability, and XA.
- Poor and/or inconsistent driver response times or data throughput performance when the driver is deployed in certain runtime environments (such as different JVMs) or with ORMs and application servers.
- The inability to tune or optimize critical applications, or the ability to do so only with considerable application downtime.
- Poor virtual machine (VM) consolidation ratios due to inefficient runtime CPU usage and high memory footprints.
- Deployment headaches such as having to deploy multiple JARs to support different JVMs or database versions, or DLLs to support certain driver or database functionality.
These limitations point to the following key trends and advances in the modern Java environment as the sources of today's Type 4 driver challenges:
- Application support of multiple databases
- Increased server virtualization and data center consolidation
- Rapid adoption of ORM models such as Hibernate or app servers such as JBoss that sit on top of JDBC drivers and permit no access to JDBC code