JDBC Type 5 Drivers Needed to Overcome Type 4 Limitations, Page 2
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.
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 AuthorJonathan Bruce is the Product Manager for Progress Software's Connect, Open Access, SequeLink and upcoming Cloud product lines. With more than 10 years of broad technical experience with data access challenges across the Java, .NET, native and mainframe platforms, Jonathan is responsible for charting the product strategy for Progress DataDirect products. Jonathan is author of JSR efforts contributing to the J2SE and J2EE platforms, recipient of patent awards, and also co-author of the book "JDBC API Tutorial and Reference, Third Edition".
Page 2 of 2