Posted in: JDBC,JDBC Drivers
Types of JDBC drivers
This topic defines the
Java(TM) Database Connectivity (JDBC) driver types. Driver types are used to
categorize the technology used to connect to the database. A JDBC driver vendor
uses these types to describe how their product operates. Some JDBC driver types
are better suited for some applications than others.
There are
four types of JDBC drivers known as:
- JDBC-ODBC bridge plus ODBC driver, also called Type 1.
- Native-API, partly Java driver, also called Type 2.
- JDBC-Net, pure Java driver, also called Type 3.
- Native-protocol, pure Java driver, also called Type 4.
Type 1 Driver- the JDBC-ODBC
bridge :
The JDBC type 1 driver, also
known as the JDBC-ODBC bridge is a database driver implementation that employs
the ODBC driver to connect to the database. The driver converts JDBC method
calls into ODBC function calls. The bridge is usually used when there is no
pure-Java driver available for a particular database.
The driver is implemented in
the sun.jdbc.odbc.JdbcOdbcDriver class and comes with the Java 2 SDK, Standard
Edition. The driver is platform-dependent as it makes use of ODBC which in turn
depends on native libraries of the operating system. Also, using this driver
has got other dependencies such as ODBC must be installed on the computer
having the driver and the database which is being connected to must support an
ODBC driver. Hence the use of this driver is discouraged if the alternative of
a pure-Java driver is available.
Type 1 is the simplest of all
but platform specific i.e only to Microsoft platform.
A JDBC-ODBC bridge provides
JDBC API access via one or more ODBC drivers. Note that some ODBC native code
and in many cases native database client
code must be loaded on each client machine that uses this type of driver.
Hence, this kind of driver is generally
most appropriate when automatic installation and downloading of a Java
technology application is not important. For information on the JDBC-ODBC
bridge driver provided by Sun, see JDBC-ODBC Bridge Driver.
Type 1 drivers are
"bridge" drivers. They use another technology such as Open Database
Connectivity (ODBC) to communicate with
a database. This is an advantage because ODBC drivers exist for many Relational
Database Management System (RDBMS) platforms. The Java Native Interface (JNI)
is used to call ODBC functions from the JDBC driver.
A Type 1 driver needs to have
the bridge driver installed and configured before JDBC can be used with it.
This can be a serious drawback for a production application. Type 1 drivers
cannot be used in an applet since applets cannot load native code.
Functions:
Translates query obtained by JDBC into
corresponding ODBC query, which is then handled by the ODBC driver.
Sun provides a JDBC-ODBC Bridge
source.
Client -> JDBC Driver
-> ODBC Driver -> Database
There is some overhead
associated with the translation work to go from JDBC to ODBC.
Advantages:
Almost any database for which
ODBC driver is installed, can be accessed.
Disadvantages:
Performance overhead since
the calls have to go through the JDBC overhead bridge to the ODBC driver, then
to the native database connectivity interface.
The ODBC driver needs to be
installed on the client machine.
Considering the client-side
software needed, this might not be suitable for applets.
Type 2 Driver - the
Native-API Driver:
The JDBC type 2 driver, also
known as the Native-API driver is a database driver implementation that uses
the client-side libraries of the database. The driver converts JDBC method
calls into native calls of the database API.
The type 2 driver is not
written entirely in Java as it interfaces with non-Java code that makes the
final database calls.
The driver is compiled for
use with the particular operating system. For platform interoperability, the
Type 4 driver, being
a full-Java implementation,
is preferred over this driver.
A native-API partly Java
technology-enabled driver converts JDBC calls into calls on the client API for
Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge
driver, this style of driver requires that some binary code be loaded on each
client machine.
However the type 2 driver
provides more functionality and performance than the type 1 driver as it does
not have the overhead of the additional ODBC function calls.
Type 2 drivers use a native
API to communicate with a database system. Java native methods are used to
invoke the API functions that perform database operations. Type 2 drivers are
generally faster than Type 1 drivers.
Type 2 drivers need native
binary code installed and configured to work. A Type 2 driver also uses the
JNI. You cannot use a Type 2 driver in an applet since applets cannot load
native code. A Type 2 JDBC driver may require some Database Management System
(DBMS) networking software to be installed.
The Developer Kit for Java
JDBC driver is a Type 2 JDBC driver.
Functions:
This type of driver converts
JDBC calls into calls to the client API for that database.
Client -> JDBC Driver
-> Vendor Client DB Library -> Database
Advantage
Better performance than Type
1 since no jdbc to odbc translation is needed.
Disadvantages
The vendor client library
needs to be installed on the client machine.
Cannot be used in internet
due the client side software needed.
Not all databases give the
client side library.
Type 3 driver - the
Network-Protocol Driver:
The JDBC type 3 driver, also
known as the network-protocol driver is a database driver implementation which
makes use of a middle-tier between the calling program and the database. The
middle-tier (application server) converts JDBC calls directly or indirectly
into the vendor-specific database protocol.
This differs from the type 4
driver in that the protocol conversion logic resides not at the client, but in
the middle-tier. However, like type 4 drivers, the type 3 driver is written
entirely in Java.
The same driver can be used
for multiple databases. It depends on the number of databases the middleware
has been configured to support. The type 3 driver is platform-independent as
the platform-related differences are taken care by the middleware. Also, making
use of the middleware provides additional advantages of security and firewall
access.
A net-protocol fully Java
technology-enabled driver translates JDBC API calls into a DBMS-independent net
protocol which is then translated to a DBMS protocol by a server. This net
server middleware is able to connect all of its Java technology-based clients
to many different databases. The specific protocol used depends on the vendor.
In general, this is the most flexible JDBC API alternative. It is likely that
all vendors of this solution will provide products suitable for Intranet use.
In order for these products to also support Internet access they must handle
the additional requirements for security, access through firewalls, etc., that
the Web imposes. Several vendors are adding JDBC technology-based drivers
to their existing database middleware
products.
These drivers use a
networking protocol and middleware to communicate with a server. The server
then translates the protocol to DBMS function calls specific to DBMS.
Type 3 JDBC drivers are the
most flexible JDBC solution because they do not require any native binary code
on the client. A Type 3 driver does not need any client installation.
Functions:
Follows a three tier
communication approach.
Can interface to multiple
databases - Not vendor specific.
The JDBC Client driver
written in java, communicates with a middleware-net-server using a database
independent protocol, and then this net
server translates this request into database commands for that database.
Thus the client driver to
middleware communication is database independent.
Client -> JDBC Driver
-> Middleware-Net Server -> Any Database
Advantages
Since the communication
between client and the middleware server is database independent, there is no
need for the vendor db library on the client machine. Also the client to
middleware need'nt be changed for a new database.
The Middleware Server (Can be
a full fledged J2EE Application server) can provide typical middleware services
like caching (connections, query results, and so on), load balancing, logging,
auditing etc..
eg. for the above include
jdbc driver features in Weblogic.
Can be used in internet since
there is no client side software needed.
At client side a single
driver can handle any database.(It works provided the middlware supports that
database!!)
Disadvantages
Requires database-specific
coding to be done in the middle tier.
An extra layer added may result in a
time-bottleneck. But typically this is overcome by providing efficient
middleware
services described above.
Type 4 - the Native-Protocol
Driver:
The JDBC type 4 driver, also
known as the native-protocol driver is a database driver implementation that
converts JDBC calls directly into the vendor-specific database protocol.
The type 4 driver is written
completely in Java and is hence platform independent. It is installed inside
the Java Virtual Machine of the client. It provides better performance over the
type 1 and 2 drivers as it does not have the overhead of conversion of calls
into ODBC or database API calls. Unlike the type 1 and 2 drivers, it does not
need associated software to work.
A native-protocol fully Java
technology-enabled driver converts JDBC technology calls into the network
protocol used by DBMSs directly. This allows a direct call from the client
machine to the DBMS server and is a practical solution for Intranet access.
Since many of these protocols are proprietary the database vendors themselves
will be the primary source for this style of driver. Several database vendors
have these in progress.
As the database protocol is
vendor-specific, separate drivers, usually vendor-supplied, need to be used to
connect to the database.
A Type 4 driver uses Java to
implement a DBMS vendor networking protocol. Since the protocols are usually
proprietary, DBMS vendors are generally the only companies providing a Type 4
JDBC driver.
Type 4 drivers are all Java
drivers. This means that there is no client installation or configuration.
However, a Type 4 driver may not be suitable for some applications if the
underlying protocol does not handle issues such as security and network
connectivity well.
The IBM Toolbox for Java JDBC
driver is a Type 4 JDBC driver, indicating that the API is a pure Java
networking protocol driver.
Functions
Type 4 drivers are entirely
written in Java that communicate directly with a vendor's database through
socket connections. No translation or middleware layers, are required,
improving performance.
The driver converts JDBC
calls into the vendor-specific database protocol so that client applications
can communicate directly with the database server.
Completely implemented in
Java to achieve platform independence.
e.g include the widely used
Oracle thin driver - oracle.jdbc.driver. OracleDriver which connect to
jdbc:oracle:thin URL format.
Client Machine -> Native
protocol JDBC Driver -> Database server
Advantages
These drivers don't translate
the requests into db request to ODBC or pass it to client api for the db, nor
do they need a middleware layer for request indirection. Thus the performance
is considerably improved.
Disadvantage
At client side, a separate
driver is needed for each database.