Architecture of the Microsoft JDBC Driver for SQL Server
I recently began investigating the Microsoft JDBC Driver for SQL Server (see my Getting Started with the SQL Server JDBC Driver post for more information). In this post I’ll continue that investigation by looking at the architecture and history of the driver. While the information in this post may not all be immediately useful when building Java applications, I found it interesting to learn.
The first step to understanding the architecture of the JDBC driver is to realize that the JDBC specification calls out 4 driver types that generally increase in performance and flexibility from type 1 to type 4. The JDBC Driver for SQL Server is a JDBC type 4 driver. To be a type 4 driver, two simple criteria have to be met, but the benefits of meeting those simple criteria are significant. The criteria are…
- The driver is written completely in Java.
- The driver converts JDBC calls directly in to a vendor specific database protocol (TDS in the case of SQL Server).
Because of these criteria, a type 4 of driver is sometimes called a “native protocol driver” or a “direct-to-database, pure java driver”. More importantly, there are two significant benefits of being a type 4 driver (with some interesting side benefits). Because the driver is written completely in Java, the driver installs inside the Java Virtual Machine (JVM). This means that the driver is platform-independent (it will run on any platform that supports Java) and that application-to-database communication (i.e. JDBC calls) can be debugged – obviously a huge benefit when building apps. And, because the driver converts JDBC calls directly into TDS (in the case of SQL Server), performance is enhanced because no middle-layer translation into SQL Server protocol must occur.
The driver architecture can be summarized (and some of the benefits inferred) in the following diagram:
Since 2004, the JDBC team at Microsoft has been busy releasing new versions of the JDBC Driver for SQL Server that surface new features, support new releases of SQL Server (and most recently, SQL Azure), and bring the driver into compliance with new JDBC specifications. Their work can be summarized as follows:
- SQL 2000 Driver (May 2004) (This release is no longer supported, and
the naming convention for the driver changed in subsequent releases.)
- Support for SQL Server 2000
- JDBC Driver 1.0 (January 2006)
- Support for essential features in SQL Server 2005
- JDBC Driver 1.1 (August 2006)
- Support for advanced features in SQL Server 2005
- Compliant with JDBC 3.0 specification
- JDBC Driver 1.2 (October 2007)
- Support for enterprise-level feature set in SQL Server 2005
- JDBC Driver 2.0 (March 2009)
- Support for enterprise-level feature set in SQL Server 2008
- Compliant with JDBC 4.0 specification
- JDBC Driver 3.0 (April 2010)
- Support for enterprise-level feature set in SQL Server 2008 R2
- Added support for Date, Time, Unicode, and XML data types
- Added support for SQL Azure access (February 2011)
On a practical note, the following is important to know about compatibility with different JVM versions:
- The 1.2 release of the JDBC Driver for SQL Server is compatible with JVM 1.4
- The 2.0 and 3.0 releases are compatible with JVM 1.5 and 1.6.
Like I said earlier, not all information immediately applicable when building an application, but nice background information to have.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)