To connect to a database using Java, most of us use JDBC API.
We normally include driver like ojdbc14 (Intended for Java 1.4) in class path, and in program we use Class.forName to use it.
Unlike in most other jars the imports are not from ojdbc14, they are from java.sql which is in rt.jar itself. So which type of driver (1,2,3,4) is used for each of these?
Advertisement
Answer
you are using the jdbc interface from java.sql classes, so the type of driver will not have any logic impact in your code, it will only have runtime / deployment impact.
You are also using the ojdb14.jar from Oracle, probably with a “thin” jdbc configuration, which means you are using a type-4 driver configuration. With such a configuration, you will only need to deploy the JDBC jar file with your database accessing program.
The other options include a JDBC bridge, which really means an ODBC connection wrapped in JDBC clothing. This means you would have to configure your system for correct ODBC function, and then use a JAR file to access ODBC. Due to the extra “hop” of data through ODBC, one would expect it to be a bit slower than a type-4 access; however, there is a possibility that the ODBC is optimized to such a great extent for a particular situation, that the extra hop is negligible. As with most performance concerns, the truth is discovered by testing (in your environment).
The type-2 drivers again use a Java (JDBC) API; however, they bridge the calls into a C or C++ style shared library, which then handles the real connection. If the driver is optimized to be so fast that the JNI setup / tear down calls are negligible in cost, then perhaps it might outperform type-4 drivers.
Type 3 drivers basically proxy (or relay) the request to another network resource. That typically incurs an extra network hit, but again, that doesn’t say much about actual performance.
Type 4 drivers are the ones you probably want to stick with. The Java program connects directly to the database, meaning that if there is a problem, it will be captured entirely within the JVM of the program making the connection (type 1, it’s in the ODBC layer, type 2 it’s in the native compiled code, type 3 it’s in the remote network proxy).
Again none of this has to do with functionality; however, they all impact how to deploy, how to debug, and how to configure the database connection.