This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm guessing you are talking about Oracle's thin driver?
Sun's JDBC-ODBC bridge is a type 1 driver. All the driver does is provides a connection to ODBC functionality supplied by the client machine the driver is installed on. As such it requires ODBC software is installed on the client machine. It also only supports a sub-set of the JDBC API functionality.
Oracle's thin driver is a type 4 driver. This type of driver talks directly to the database via some protocol (e.g. TCP/IP). As such it doesn't require anything else be installed on the client machine.
Have a look at the JDBC guide supplied by Sun. [ September 08, 2006: Message edited by: Paul Sturrock ]
Not really. The vast majority of drivers were not written by Sun, so they are almost all third party drivers. Better to call it a "type 1" driver, since that is the term used in the JDBC specification, so is the term most likely to be understood by others.
You should use the JDBC/ODBC bridge when multiple connections are not required. Multiple instances of your application can create and close connections using the bridge, but this is far less efficient than using a connection pool.
The third party database drivers (e.g. Oracle, MySQL) adhere to the JDBC spec provided by Sun, which enables them to abide by a single contract across multi-vendor application servers (e.g. JBoss, Websphere). If your J2SE application enabled pooling as per the JDBC spec, it too could use Oracle's thin driver.
If your (web) application is hosted on a application server, you can retreive the datasource using the JNDI initial context (thereby leaving the pooling work up to the app server).