JDBC Driver |
|
JDBC Driver Manager |
|
The JDBC DriverManager class defines objects which can connect Java applications to a JDBC driver. DriverManager has traditionally been the backbone of the JDBC architecture. It is quite small and simple. |
|
This is a very important class. Its main purpose is to provide a means of managing the different types of JDBC database driver. On running an application, it is the DriverManager’s responsibility to load all the drivers found in the system property jdbc. drivers. For example, this is where the driver for the Oracle database may be defined. This is not to say that a new driver cannot be explicitly stated in a program at runtime which is not included in jdbc.drivers. When opening a connection to a database it is the DriverManager’ s role to choose the most appropriate driver from the previously loaded drivers. |
|
The JDBC API defines the Java interfaces and classes that programmers use to connect to databases and send queries. A JDBC driver implements these interfaces and classes for a particular DBMS vendor. |
|
A Java program that uses the JDBC API loads the specified driver for a particular DBMS before it actually connects to a database. The JDBC DriverManager class then sends all JDBC API calls to the loaded driver. |
|
JDBC Driver |
|
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. |
|
Types of JDBC drivers |
|
JDBC drivers are divided into four types or levels. Each type defines a JDBC driver implementation with increasingly higher levels of platform independence, performance, and deployment administration. The four types are: |
|
• Type 1: JDBC-ODBC Bridge |
|
• Type 2: Native-API/partly Java driver |
|
• Type 3: Net-protocol/all-Java driver |
|
• Type 4: Native-protocol/all-Java driver |
|
Type 1: JDBC-ODBC Bridge |
|
The type 1 driver, JDBC-ODBC Bridge, translates all JDBC calls into ODBC (Open DataBase Connectivity) calls and sends them to the ODBC driver. As such, the ODBC driver, as well as, in many cases, the client database code, must be present on the client machine. Figure shows a typical JDBC-ODBC Bridge environment. |
|
 |
|
Type 1: JDBC-ODBC Bridge |
|
Functions: |
|
1. Translates query obtained by JDBC into corresponding ODBC query, which is then handled by the ODBC driver. |
|
2. Sun provides a JDBC-ODBC Bridge driver. sun.jdbc.odbc.JdbcOdbcDriver. This driver is native code and not Java, and is closed source. |
|
3. Client -> JDBC Driver -> ODBC Driver -> Database |
|
4. There is some overhead associated with the translation work to go from JDBC to ODBC. |
|
Pros |
|
The JDBC-ODBC Bridge allows access to almost any database, since the database’s ODBC drivers are already available. Type 1 drivers may be useful for those companies that have an ODBC driver already installed on client machines. |
|
Cons |
|
• The performance is degraded since the JDBC call goes through the bridge to the ODBC driver, then to the native database connectivity interface. The result comes back through the reverse process. Considering the performance issue, type 1 drivers may not be suitable for large-scale applications. |
|
• The ODBC driver and native connectivity interface must already be installed on the client machine. Thus any advantage of using Java applets in an intranet environment is lost, since the deployment problems of traditional applications remain. |
|
Type 2: Native-API/partly Java driver |
|
JDBC driver type 2 — the native-API/partly Java driver — converts JDBC calls into database-specific calls for databases such as SQL Server, Informix, Oracle, or Sybase. The type 2 driver communicates directly with the database server; therefore it requires that some binary code be present on the client machine. |
|
 |
|
Type 2: Native-API/partly Java driver |
|
Functions: |
|
1. This type of driver converts JDBC calls into calls to the client API for that database. |
|
2. Client -> JDBC Driver -> Vendor Client DB Library -> Database |
|
Pros |
|
Type 2 drivers typically offer significantly better performance than the JDBC-ODBC Bridge. |
|
Cons |
|
The vendor database library needs to be loaded on each client machine. Consequently, type 2 drivers cannot be used for the Internet. Type 2 drivers show lower performance than type 3 and type 4 drivers. |
|
Type 3: Net-protocol/all-Java driver |
|
JDBC driver type 3 — the net-protocol/all-Java driver — follows a three-tiered approach whereby the JDBC database requests are passed through the network to the middle-tier server. The middle-tier server then translates the request (directly or indirectly) to the database-specific native-connectivity interface to further the request to the database server. If the middle-tier server is written in Java, it can use a type 1 or type 2 JDBC driver to do this. |
|
 |
|
Type 3: Net-protocol/all-Java driver |
|
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 |
|
Pros |
|
The net-protocol/all-Java driver is server-based, so there is no need for any vendor database library to be present on client machines. Further, there are many opportunities to optimize portability, performance, and scalability. Moreover, the net protocol can be designed to make the client JDBC driver very small and fast to load. Additionally, a 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. |
|
Cons |
|
Type 3 drivers require database-specific coding to be done in the middle tier. Additionally, traversing the recordset may take longer, since the data comes through the backend server. |
|
Type 4: Native-protocol/all-Java driver |
|
The native-protocol/all-Java driver (JDBC driver type 4) converts JDBC calls into the vendor-specificdatabase management system (DBMS) protocol so that client applications can communicate directly with the database server. Level 4 drivers are completely implemented in Java to achieve platform independence and eliminate deployment administration issues. |
|
 |
|
Type 4: Native-protocol/all-Java 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 |
|
Pros |
|
Since 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. Moreover, the native-protocol/all-Java driver boasts better performance than types 1 and 2. Also, there’s no need to install special software on the client or server. Further, these drivers can be downloaded dynamically. |
|
Cons |
|
With type 4 drivers, the user needs a different driver for each database. |
|
All 4 Types of Driver:- |
|
 |
Types Of Drivers As shown above there are 4 types of JDBC drivers available. |
|