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…
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:
On a practical note, the following is important to know about compatibility with different JVM versions:
Like I said earlier, not all information immediately applicable when building an application, but nice background information to have.
Share this on Twitter