Introduction

JDBC is an amusing acronym in that it doesn't actually stand for anything. It's widely agreed that the "J" means Java and the DB means "database," but no one seems quite sure about the "C". Connectivity? Connection? Something like that, anyway. ^[1] JDBC is probably a play off ODBC, Microsoft's Open Database Connect utility, but at this writing no definitive expansion of the acronym exists. Regardless of what JDBC stands for, it refers to the suite of mechanisms whereby Java applications interact with databases.

^[1] Here's a mean-spirited but possibly fun office game: get the local windbag in a public situation (perhaps a meeting, but one of the periodic gatherings-with-cake would also do nicely ) and ask him/her what JDBC stands for. Express doubt at whatever answer he/she gives. Force him/her to commit. You get extra points if the windbag commits to a wager of some sort .

One problem JDBC addresses is the wide variety of database vendorsOracle, MySQL, Informix, MS-Access, and so on. The syntax of the actual SQL statements used to interact with a particular database is usually portable between vendors , more or less. However, the protocols used to interact with the database enginecreate a connection, authenticate, pass in the SQL statements, receive and return the resultsare vendor specific. If an application is written to interact directly with the database, significant code changes will be required if the vendor or even the version of the database changes.

JDBC addresses this problem by imposing itself as in intermediate layer between an application and the database that the application is trying to access. The idea is that the application should make its requests for interaction with the database to the JDBC layer, not to the database itself. (See Figure 7-1.) JDBC, not the application program, is responsible for direct communication with the database.

Figure 7-1. JDBC

As you can see, JDBC is divided into two conceptual layers . The layer that deals with the client programs is the same for all vendors and all versions. Underneath it is a vendor-specific driver that can be swapped in and out as needed. The application processes don't need to care if they are talking to Oracle 8.0.5 or MySQL 3.2JDBC handles those details for them. The transparency, as this property is called, isn't absolutely perfectthere can still be some vendor-specific variations in SQL syntax, and a few other quibblesbut it is dramatically better than the vendor-dependent architecture that it supplants.

JDBC drivers come in four types:

Type 1	Type 1 drivers are a JDBC-ODBC bridge. They were the first type implemented. Even fanatic Sun boosters will admit that these drivers are a quick-and-dirty fix. Sun apparently felt a certain amount of pressure to put out a product that could compete with ODBC. Type 1 drivers are a direct map from the JDBC API to the ODBC API.
Type 2	Type 2 drivers are a map from the JDBC API to the network libraries provided by the database vendor.
Type 3	Type 3 drivers implement a middle tier for database access. The middle tier houses drivers for one or more data sources, and the client application interacts with it rather than housing libraries locally. Among other things, this circumvents an applet security property that says an applet may directly interact with only one data source.
Type 4	Type 4 drivers are the Java ideal. Rather than relying on interaction with intermediate libraries, they are implemented entirely in Java.

Choosing a JDBC Driver

A number of Type 2 and Type 4 drivers are provided with the WebLogic distribution. They do not require specific installation. Additional JDBC drivers are available from:

http://industry.java.sun.com/products/jdbc/drivers

This chapter discusses the administration of JDBC as it relates to the WebLogic server.