What is JDBC Driver ?

JDBC drivers implement the defined interfaces in the JDBC API for
interacting with your database server.
For example, using JDBC drivers enable you to open database connections
and to interact with it by sending SQL or database commands then receiving
results with Java.
The Java.sql package that ships with JDK contains various classes with their
behaviours defined and their actual implementaions are done in third-party
drivers. Third party vendors implements the java.sql.Driver interface in their
database driver.
JDBC Drivers Types:
JDBC driver implementations vary because of the wide variety of operating
systems and hardware platforms in which Java operates. Sun has divided the
implementation types into four categories, Types 1, 2, 3, and 4, which is
explained below:
Type 1: JDBC-ODBC Bridge Driver:
In a Type 1 driver, a JDBC bridge is used to access ODBC drivers installed
on each client machine. Using ODBC requires configuring on your system a
Data Source Name (DSN) that represents the target database.
When Java first came out, this was a useful driver because most databases
only supported ODBC access but now this type of driver is recommended
only for experimental use or when no other alternative is available.

The JDBC-ODBC bridge that comes with JDK 1.2 is a good example of this
kind of driver.

Type 2: JDBC-Native API:

In a Type 2 driver, JDBC API calls are converted into native C/C++ API
calls which are unique to the database. These drivers typically provided by
the database vendors and used in the same manner as the JDBC-ODBC
Bridge, the vendor-specific driver must be installed on each client machine.
If we change the Database we have to change the native API as it is specific
to a database and they are mostly obsolete now but you may realize some
speed increase with a Type 2 driver, because it eliminates ODBC's overhead.

The Oracle Call Interface (OCI) driver is an example of a Type 2 driver.

Type 3: JDBC-Net pure Java:
In a Type 3 driver, a three-tier approach is used to accessing databases. The
JDBC clients use standard network sockets to communicate with an
middleware application server. The socket information is then translated by
the middleware application server into the call format required by the
DBMS, and forwarded to the database server.
This kind of driver is extremely flexible, since it requires no code installed
on the client and a single driver can actually provide access to multiple
databases.

You can think of the application server as a JDBC "proxy," meaning that it
makes calls for the client application. As a result, you need some knowledge
of the application server's configuration in order to effectively use this driver
type.
Your application server might use a Type 1, 2, or 4 driver to communicate
with the database, understanding the nuances will prove helpful.
Type 100: 100% pure Java:
In a Type 4 driver, a pure Java-based driver that communicates directly with
vendor's database through socket connection. This is the highest
performance driver available for the database and is usually provided by the
vendor itself.
This kind of driver is extremely flexible, you don't need to install special
software on the client or server. Further, these drivers can be downloaded
dynamically.

MySQL's Connector/J driver is a Type 4 driver. Because of the proprietary

nature of their network protocols, database vendors usually supply type 4
drivers.
Which Driver should be used?

If you are accessing one type of database, such as Oracle, Sybase, or IBM,
the preferred driver type is 4.
If your Java application is accessing multiple types of databases at the same
time, type 3 is the preferred driver.
Type 2 drivers are useful in situations where a type 3 or type 4 driver is not
available yet for your database.
The type 1 driver is not considered a deployment-level driver and is
typically used for development and testing purposes only.

JDBC Driver Types

JDBC drivers are divided into four types or levels. The different types of
jdbc drivers are:
Type 1: JDBC-ODBC Bridge driver (Bridge)
Type 2: Native-API/partly Java driver (Native)
Type 3: AllJava/Net-protocol driver (Middleware)
Type 4: All Java/Native-protocol driver (Pure)
4 types of jdbc drivers are elaborated in detail as shown below:
Type 1 JDBC Driver
JDBC-ODBC Bridge driver
The Type 1 driver translates all JDBC calls into ODBC calls and sends them
to the ODBC driver. ODBC is a generic API. The JDBC-ODBC Bridge
driver is recommended only for experimental use or when no other
alternative is available.

Type 1: JDBC-ODBC Bridge

Advantage
The JDBC-ODBC Bridge allows access to almost any database, since the
database's ODBC drivers are already available.
Disadvantages
1. Since the Bridge driver is not written fully in Java, Type 1 drivers are not
portable.
2. A performance issue is seen as a JDBC call goes through the bridge to the
ODBC driver, then to the database, and this applies even in the reverse
process. They are the slowest of all driver types.
3. The client system requires the ODBC Installation to use the driver.
4. Not good for the Web.
Type 2 JDBC Driver
Native-API/partly Java driver

The distinctive characteristic of type 2 jdbc drivers are that Type 2 drivers
convert JDBC calls into database-specific calls i.e. this driver is specific to a
particular database. Some distinctive characteristic of type 2 jdbc drivers are
shown below. Example: Oracle will have oracle native api.

Type 2: Native api/ Partly Java Driver

Advantage
The distinctive characteristic of type 2 jdbc drivers are that they are typically
offer better performance than the JDBC-ODBC Bridge as the layers of
communication (tiers) are less than that of Type
1 and also it uses Native api which is Database specific.
Disadvantage
1. Native API must be installed in the Client System and hence type 2
drivers cannot be used for the Internet.
2. Like Type 1 drivers, its not written in Java Language which forms a
portability issue.
3. If we change the Database we have to change the native api as it is
specific to a database
4. Mostly obsolete now
5. Usually not thread safe.

Type 3 JDBC Driver

All Java/Net-protocol driver
Type 3 database requests are passed through the network to the middle-tier
server. The middle-tier then translates the request to the database. If the
middle-tier server can in turn use Type1, Type 2 or Type 4 drivers.

Type 3: All Java/ Net-Protocol Driver

Advantage
1. This driver is server-based, so there is no need for any vendor database
library to be present on client machines.
2. This driver is fully written in Java and hence Portable. It is suitable for the
web.
3. There are many opportunities to optimize portability, performance, and
scalability.
4. The net protocol can be designed to make the client JDBC driver very
small and fast to load.
5. The type 3 driver typically provides support for features such as caching
(connections, query results, and so on), load balancing, and advanced
system administration such as logging and auditing.
6. This driver is very flexible allows access to multiple databases using one
driver.

7. They are the most efficient amongst all driver types.

Disadvantage
It requires another server application to install and maintain. Traversing the
recordset may take longer, since the data comes through the backend server.
Type 4 JDBC Driver
Native-protocol/all-Java driver
The Type 4 uses java networking libraries to communicate directly with the
database server.

Type 4: Native-protocol/all-Java driver

Advantage
1. The major benefit of using a type 4 jdbc drivers are that they are
completely written in Java to achieve platform independence and eliminate
deployment administration issues. It is most suitable for the web.
2. Number of translation layers is very less i.e. type 4 JDBC drivers don't
have to translate database requests to ODBC or a native connectivity
interface or to pass the request on to another server, performance is typically
quite good.
3. You dont need to install special software on the client or server. Further,
these drivers can be downloaded dynamically.

Disadvantage
With type 4 drivers, the user needs a different driver for each database.

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:
1. Follows a three tier communication approach.
2. Can interface to multiple databases - Not vendor specific.
3. 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.
4. Thus the client driver to middleware communication is database
independent.
5. Client -> JDBC Driver -> Middleware-Net Server -> Any Database
Advantages
1. 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.
2. 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..
3. eg. for the above include jdbc driver features in Weblogic.
4. Can be used in internet since there is no client side software needed.
5. At client side a single driver can handle any database.(It works
provided the middlware supports that database!!)
Disadvantages

1. Requires database-specific coding to be done in the middle tier.

2. 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
1. 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.
2. The driver converts JDBC calls into the vendor-specific database
protocol so that client applications can communicate directly with
the database server.
3. Completely implemented in Java to achieve platform independence.
4. e.g include the widely used Oracle thin driver - oracle.jdbc.driver.
OracleDriver which connect to jdbc:oracle:thin URL format.
5. 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.