JDBC - Java Database Connectivity
JDBC - Java Database Connectivity
JDBC Architecture
JDBC API
JDBC Drivers
classes available from different vendors which must be registered with JDBC DriverManager to connect to different databases
Query
Process results
Close
Stage 1: Connect
Connect
Register the driver
Query
Process results
Close
Protocol
Subprotocol
Database identifier
jdbc:oracle:thin:@<host>:<port>:<SID>
jdbc:oracle:thin:@localhost:1521:XE
Using Connection
java.sql.Connection
createStatment() prepareStatment(String) prepareCall(String) commit() rollback() getMetaData()
close() isClosed()
Stage 2: Query
Connect
Query
Create a statement
Process results
Close
executeQuery() for QUERY statements executeUpdate() for INSERT, UPDATE, DELETE, or DDL statements execute() for either type of statement
Process results
Close
Stage 4: Close
Connect
Close
JDBC Drivers
Type 1 - JDBC-ODBC Bridge driver Type 2 - Native-API/partly Java driver Type 3 - All Java/Net-protocol driver Type 4 - Native-protocol/all-Java 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 native database client code must be loaded on each client machine that uses this type of driver. The JDBCODBC Bridge driver is recommended only for experimental use or when no other alternative is available.
The JDBC-ODBC Bridge allows access to almost any database, since the database's ODBC drivers are already available.
Since the Bridge driver is not written fully in Java, Type 1 drivers are not portable. 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. The client system requires the ODBC Installation to use the driver. Not good for the Web.
The distinctive characteristic of type 2 jdbc drivers are that Type 2 drivers convert JDBC calls into databasespecific calls i.e. this driver is specific to a particular database. Like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.
The distinctive characteristic of type 2 jdbc drivers are that they are typically offer better performance than the JDBCODBC Bridge as the layers of communication (tiers) are less than that of Type 1 and also it uses Native api which is Database specific.
Native API must be installed in the Client System and hence type 2 drivers cannot be used for the Internet. Like Type 1 drivers, its not written in Java Language which forms a portability issue. If we change the Database we have to change the native API as it is specific to a database Mostly obsolete now Usually not thread safe.
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.
This driver is server-based, so there is no need for any vendor database library to be present on client machines. This driver is fully written in Java and hence Portable. It is suitable for the web. There are many opportunities to optimize portability, performance, and scalability. The net protocol can be designed to make the client JDBC driver very small and fast to load.
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. This driver is very flexible allows access to multiple databases using one driver. They are the most efficient amongst all driver types.
It requires another server application to install and maintain. Traversing the recordset may take longer, since the data comes through the backend server.
The Type 4 drivers take JDBC calls and translates them into the network protocol using java networking libraries to communicate directly with the database server.
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. 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.
You don't need to install special software on the client or server. Further, these drivers can be downloaded dynamically.
With type 4 drivers, the user needs a different driver for each database.
Administrative Tools
User DSN
Add Finish