An application that does not persist its data in a database is a rarity. Programming languages reflect this trend. That's why all languages provide a robust and flexible library for database access. Java is no exception.
Java provides the Java Database Connectivity (JDBC) API to access different databases. In this discussion, I will be focusing on the basics of JDBC. I will start with the whys and wherefores of JDBC. The next section will focus on the steps to use JDBC to access a database. In the final section, I will develop an application that will access MySQL database server using the steps described in the previous section. That's the outline for this discussion.
JDBC: What is it?
JDBC, which is short for Java Database Connectivity, can be defined as "An API for the Java programming language that defines how a client may access a database." In other words, JDBC specifies the ways and methods that are needed to access a database, more specifically a relational database such as Oracle, MySQL, and others. The main aspect of JDBC is that it is a specification and not a product. So different vendors (here RDBMS vendors) provide their own implementation for the specification.
For example, the JDBC implementation for Oracle database is provided by Oracle itself and the same is the case for all others. The implementations provided by the vendors are known as JDBC Drivers. The most important point to be kept in mind is that JDBC Drivers are installed at client-side and not at server-side.
JDBC has been with the Java Standard Edition (JSE) from version 1.1. The latest version is 4 and is being shipped with JSE 6. Regardless of the version, JDBC supports four types of implementations or drivers. They are:
1. Type I or JDBC-ODBC Bridge
2. Type II or Partly Java Partly Native
3. Type III or Network Protocol Driver
4. Type IV or Pure Java Driver
The types are defined by how the driver provides communication between the application and the database server. Here are the details.
A Type I Driver is also called a JDBC-ODBC Bridge. The reason is that in this case JDBC internally makes calls to the ODBC. It is the ODBC that communicates with the database server. The job of JDBC is to provide the queries to the ODBC in a form understandable by ODBC and to deliver the result provided by ODBC to the application in a form that is understandable by the application. This Driver works mainly with the Windows platform. This is the only type of Driver that is shipped with a Java installation.
A Type II Driver uses the native API of the target database server to communicate with the server. Hence it is known as a Native Protocol Driver as well as a Partly Java Partly Native Driver. This Driver doesn't contain pure Java code as it uses the client-side API provided by the target database server. To call the client-side API of the database, it uses JNI. However, since it doesn't have the overhead of calling ODBC, a Type II Driver is faster than a Type I. Also, by using a Type II Driver, one can access functionalities that are specific to the database server which is being used.
A Type III Driver is also known as Network Protocol Driver. Type III Drivers target the middleware. The middleware then communicates with the database server. In essence, Type III Drivers are like Type I with the exception that Type III Drivers are completely written in Java and use the network protocol of the middleware instead of ODBC API. Type III Drivers are more secure since middleware is in the picture. In a nutshell, in Type III Drivers the conversion logic is at the middleware level and not at the client-side.
The Type IV Driver is known as a Pure Java Driver. It is comparable to Type II as it directly interacts with the database server. Unlike Type II, Type IV doesn't use native API calls. Instead the API has been written in Java by the vendor. Apart from being a pure Java implementation of database client API, a Type IV Driver delegates the processing to the database server. That means at client side no processing related to the database or SQL translation occurs. The only job the client does is connecting to the server, passing the queries and input to the database server and getting the result back through the same connection. Due to the delegation of all the processes to the server, the Type IV Driver is also known as the Thin Client Driver.
The choice of which driver to use depends on the type of application that is being developed. For example, if the application is web-based, the best option is Type IV as it releases the application server from being a part of database transactions. In this case the application server would only have to provide services to look up the name of the connection pool and maintain the pool. All other data-related operations would be delegated to the database server. Next we will discuss the steps involved in using JDBC.
Offers Development Services For