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

The Promise of Type 5

So, how would a Type 5 driver address all these limitations? Apart from the superior client-side, single-tier, 100% Java architecture of Type 4 drivers, what other characteristics would a Type 5 driver have?

• Unrestricted performance -- The driver should be capable of delivering maximized and consistent data throughput regardless of the runtime environment or data-access model.
• Codeless enhancement -- The driver should offer the ability to add, configure, or tune features and functionality for any application without requiring any changes to application code, regardless of environment or data-access model. While this is, of course, pursuant to unrestricted performance, it is also important for ensuring that new database or driver functionality is available across all supported JVMs or hardware and can be accessed despite the use of ORM or app server models that prevent access to the JDBC code, which is required to enable such features and functionality. Comprehensive driver-connection options are a way in which this could be accomplished.
• Resource efficiency -- The use of application runtime CPU and memory should be minimized, and should be tunable in the driver to fit specific runtime environment parameters or limits. The consumption of such resources by middleware data-access operations is often overlooked until it adversely impacts server consolidation goals in virtualization initiatives.
• All-in-one deployment -- A JDBC Type 5 driver should require a single JAR file, regardless of Java environment or application requirements. It should require no client libraries or external DLLs, regardless of the deployment environment or features used by the application -- including bulk data loading, security, high availability, and XA features.
• Streamlined standard -- A JDBC Type 5 driver ought to require no proprietary extensions to the JDBC specification for any supported data source. This would address the requirement, typical of most Type 4 drivers, for proprietary code to support features such as BLOBs and CLOBs, high availability, and XA.

While a formal committee approval of a new JDBC standard would be preferable in the long run, the current limitations of Type 4 drivers frankly have become too glaring and counterproductive to wait for that drawn-out process. Organizations that rely on modern data-driven Java applications need to be able to implement JDBC Type 5 drivers now.

Suppose you could run eight VMs on a server instead of four by merely tweaking some configuration settings in a JDBC driver. This is an entirely plausible scenario where a Type 5 driver can enhance the overall usefulness of the application stack and overall IT environment much more easily than by any other available solution. Think of the application stack as a lever and the enhancements as a fulcrum. The further back on the lever the fulcrum is placed, the greater the leverage. This analogy applies to JDBC drivers at the data-connectivity level -- provided they are built to deliver the enhancements discussed here, very simple and nonintrusive changes can have dramatic impact on how the entire application stack performs.

What this all means is that developers could enhance the modern data-driven Java applications within their organizations by expanding their feature sets, performance, and reliability without making major application changes, which would save the organizations time and money.

JDBC Type 5 Drivers Needed Today

Advances in technology have left standard JDBC Type 4 drivers lacking. It is time for Java developers and architects to wake up to the reality of Type 4 JDBC drivers as the source of many problems and the possibility of Type 5 JDBC drivers as the solution.

About the Author