Mike Frost is a Program Manager for Progress Software.
In recent years, the Java ecosystem has evolved quite dramatically on a number of fronts. As a result, IT organizations are taking advantage of an array of new technologies that promise to streamline Java development cycles and reduce operating costs.
In complex enterprise computing environments, however, everything is connected and not all architectural components evolve in concert. Therefore, the introduction of advanced technologies at specific points in the architectural stack often exposes many downstream technological limitations.
As a result, businesses struggle to realize the return on investment promised by these new technologies and in some cases, even experience problems that take them a step backward rather than forward. Today, enterprise architects and developers experience this phenomenon when they task overmatched Type 4 JDBC database drivers with the ever-increasing demands of the modern Java environment.
The JDBC Driver: An Architectural Afterthought
The JDBC API specification and the drivers it enables have certainly evolved over time, from the original JDBC-ODBC bridge to the native-protocol Type 4 drivers that are so prevalent today. At this point, however, that evolution is stagnant. The majority of Type 4 JDBC drivers essentially offer the same basic features and capabilities, so for many developers, JDBC access is essentially an architectural afterthought that requires little attention.
This perception grew with the increasing adoption of Object-Relational Mapping (ORM) technologies (JPA, Hibernate, and Spring, among others), or application servers such as JBoss that sit on top of JDBC. With these modern development platforms, many developers no longer program directly to JDBC.
With no access to underlying JDBC calls, developers almost never think about JDBC or what JDBC driver to use as part of determining a data access strategy. Therefore, product evaluation means simply selecting a JDBC driver based on "checklisting." If there is a free Type 4 JDBC driver available, the driver is automatically assumed to be adequate for any use case.
Beyond ORM adoption, there have been other key technological advancements at work in the Java universe. Virtualization now delivers massive scalability on an affordable growth curve, placing a much higher value than ever before on optimum performance throughout the entire application stack. The increasingly complex features of relational databases frequently involve complicated and proprietary implementations that make them all but inaccessible to most applications. These strategic technologies are quickly finding acceptance in the enterprise marketplace, directing renewed attention on JDBC components, and placing a revealing spotlight on the shortcomings on Type 4 drivers as well as the negative impact these shortcomings have on IT performance and costs.
Type 4 JDBC Driver: Glaring Limitations
Despite superiority over other JDBC architecture types, Type 4 drivers have failed to keep up with the evolutionary advancement of complimentary Java technologies. As a result, most Type 4 drivers come with glaring limitations in today's Java-based enterprise application environments.
- Slow or Inconsistent Performance. The response time and data throughput performance of many Type 4 drivers is poor or inconsistent, particularly when deployed into certain runtime environments (such as different JVMs) or with modern data access models (ORMs and app servers).
- Unavailable or Inaccessible Functionality. Enabling or tuning critical functionality with many Type 4 JDBC drivers requires access to JDBC code, which is not available to applications deployed with ORM frameworks or in app servers. New database or driver functionality may also not be available across all supported JVMs or environments.
- Poor Resource Efficiency. Most Type 4 JDBC drivers use excessive amounts of CPU and memory resources during data access. Tuning options, if available, are inaccessible or limited. This leads to excessive usage of CPU resources and a disproportionately large memory footprint.
- Application Deployment Restrictions. Most Type 4 JDBC drivers require multiple JAR files to support different JVMs or database versions. They also typically require the deployment of platform-dependent DLLs or shared libraries to support certain driver or database functionality, limiting what environments they can be deployed to.
- Proprietary Implementation. Many Type 4 JDBC drivers require proprietary code for applications to leverage features such as BLOBs and CLOBs, high availability, and XA. As more and more data sources must be accessed from a single application, the amount of application code, and potential for bugs, increases significantly.
Many developers and architects find out the hard way, after a project has gone into production, that even the most common Type 4 JDBC drivers exhibit most, if not all, of these limitations. As businesses look to new technologies such as virtualization to improve performance and reduce costs, the cost of dealing with the deficiencies of Type 4 JDBC drivers will only increase.