There are four types of JDBC database driver:
The JDBC/ODBC bridge driver (Type 1) A piece of native C-code that translates a JDBC call to an ODBC call. Use this driver for development, not for industrial-strength application environments. Note that you have to have an ODBC database driver manager + an ODBC database driver installed on the server in addition to the JDBC/ODBC bridge. Though useful for learning JDBC and quick testing, bridging solutions are rarely appropriate for production environments.
Native API partly java driver (Type 2) A piece of native C-code that translates a java JDBC call to a native database call level API. Use this driver for development and deployment. Due to its native code, this driver can only be used by Java Applications with full computer access (i.e. not Applets). Type 2 drivers generally provide the best performance, but they require the installation of native libraries on clients that need to access the database. Applications using Type 2 drivers have a limited degree of portability.
JDBC-Net pure Java driver (Type 3) A piece of pure java code that translates an incoming JDBC call to an outgoing database Net protocol call (such as SQL*Net). Use this driverfor development and deployment. Flexible and powerful, this driver can be used by any Java component and requires only connect access to work. The Type 3 architecture is actually more of a benefit to driver vendors than application architects since it enables the vendor to write a single implementation and claim support for any database that has a JDBC driver. Though this driver type is quite powerful but, unfortunately, it has weak performance and unpredictable stability.
Native protocol pure Java driver (Type 4) A piece of pure java code that translates an incoming JDBC call to an outgoing database native protocol call (such as Oracle CLI). Use this driver for development and deployment. This driver type is the recommended one for server-side java development unless a type 2 driver has considerable performance advantages.
Practically speaking, Type 2 and Type 4 drivers are the only viable choices for a production application. At an abstract level, the choice between Type 2 and Type 4 comes down to a single issue: is platform independence critical? By platform independence, I mean that the application can be bundled up into a single jar and run on any platform. Type 2 drivers have a hard time with platform independence since you need to package platform-specific libraries with the application. If the database access API has not been ported to a client platform, your application will not run on the platform. On the other hand, Type 2 drivers tend to perform better than Type 4 drivers.
Always remember, knowing the driver type provides only a starting point for making a decision about which JDBC driver to use in your application. The decision really comes down to knowing the drivers that exist for your database of choice and how they compare to each other.
Useful Links : List of JDBC Drivers
The JDBC/ODBC bridge driver (Type 1) A piece of native C-code that translates a JDBC call to an ODBC call. Use this driver for development, not for industrial-strength application environments. Note that you have to have an ODBC database driver manager + an ODBC database driver installed on the server in addition to the JDBC/ODBC bridge. Though useful for learning JDBC and quick testing, bridging solutions are rarely appropriate for production environments.
Native API partly java driver (Type 2) A piece of native C-code that translates a java JDBC call to a native database call level API. Use this driver for development and deployment. Due to its native code, this driver can only be used by Java Applications with full computer access (i.e. not Applets). Type 2 drivers generally provide the best performance, but they require the installation of native libraries on clients that need to access the database. Applications using Type 2 drivers have a limited degree of portability.
JDBC-Net pure Java driver (Type 3) A piece of pure java code that translates an incoming JDBC call to an outgoing database Net protocol call (such as SQL*Net). Use this driverfor development and deployment. Flexible and powerful, this driver can be used by any Java component and requires only connect access to work. The Type 3 architecture is actually more of a benefit to driver vendors than application architects since it enables the vendor to write a single implementation and claim support for any database that has a JDBC driver. Though this driver type is quite powerful but, unfortunately, it has weak performance and unpredictable stability.
Native protocol pure Java driver (Type 4) A piece of pure java code that translates an incoming JDBC call to an outgoing database native protocol call (such as Oracle CLI). Use this driver for development and deployment. This driver type is the recommended one for server-side java development unless a type 2 driver has considerable performance advantages.
Practically speaking, Type 2 and Type 4 drivers are the only viable choices for a production application. At an abstract level, the choice between Type 2 and Type 4 comes down to a single issue: is platform independence critical? By platform independence, I mean that the application can be bundled up into a single jar and run on any platform. Type 2 drivers have a hard time with platform independence since you need to package platform-specific libraries with the application. If the database access API has not been ported to a client platform, your application will not run on the platform. On the other hand, Type 2 drivers tend to perform better than Type 4 drivers.
Always remember, knowing the driver type provides only a starting point for making a decision about which JDBC driver to use in your application. The decision really comes down to knowing the drivers that exist for your database of choice and how they compare to each other.
Useful Links : List of JDBC Drivers
Comments
Your blog is good and a feed would certainly help get updates.
Regards,
Goldy.