SQL Zone is brought to you in partnership with:

After teaching math (and a little computer science) for 14 years, Brian changed careers in 2006 with the idea that getting out of his comfort zone would be good. So now he works as a writer and programmer at Microsoft who specializes in PHP and Windows Azure. Brian is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Architecture of the Microsoft JDBC Driver for SQL Server

03.18.2011
| 8441 views |
  • submit to reddit

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…

  1. The driver is written completely in Java.
  2. 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:

JDBC_Architecture2 

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.

Thanks.

References
Published at DZone with permission of Brian Swan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

David Martin replied on Fri, 2011/03/18 - 12:11pm

This driver appears to be a more efficient solution than jtds under some circumstances. I had to manage date/time datatypes that were a real nightmare with jtds.

Ryan Developer replied on Sat, 2011/03/19 - 9:29pm

We've experienced many lockups when using Microsoft's JDBC driver. The problems went away after switching to jTDS.   I blogged about it here:

 

http://www.ryandelaplante.com/2008/07/glassfish-lockups-were-microsofts-fault.html

http://www.ryandelaplante.com/2009/10/glassfish-lockups-and-windows-crashes.html

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.