| Contents | Prev | Next | JDBCTM Guide: Getting Started |
DriverManager class is the management layer of JDBC, working between
the user and the drivers. It keeps track of the drivers that are available and handles
establishing a connection between a database and the appropriate driver. In addition,
the DriverManager class attends to things like driver login time limits and the printing of log and tracing messages.
For simple applications, the only method in this class that a general programmer needs to use directly is DriverManager.getConnection. As its name implies,
this method establishes a connection to a database. JDBC allows the user to call
the DriverManager methods getDriver, getDrivers, and registerDriver as well
as the Driver method connect, but in most cases it is better to let the DriverManager class manage the details of establishing a connection.
DriverManager class maintains a list of Driver classes that have registered
themselves by calling the method DriverManager.registerDriver. All Driver
classes should be written with a static section that creates an instance of the class
and then registers it with the DriverManager class when it is loaded. Thus, a user
would not normally call DriverManager.registerDriver directly; it should be
called automatically by a driver when it is loaded. A Driver class is loaded, and
therefore automatically registered with the DriverManager, in two ways:
Class.forName. This explicitly loads the driver class.
Since it does not depend on any external setup, this way of loading a driver is
recommended. The following code loads the class acme.db.Driver:
Class.forName("acme.db.Driver");
If acme.db.Driver has been written so that loading it causes an instance to be
created and also calls DriverManager.registerDriver with that instance as
the parameter (as it should do), then it is in the DriverManager's list of drivers
and available for creating a connection.
java.lang.System property jdbc.drivers. This is
a list of driver classnames, separated by colons, that the DriverManager class
loads. When the DriverManager class is intialized, it looks for the system
property jdbc.drivers, and if the user has entered one or more drivers, the
DriverManager class attempts to load them. The following code illustrates
how a programmer might enter three driver classes in ~/.hotjava/properties
(HotJava loads these into the system properties list on startup):
jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.test.ourDriver;
The first call to a DriverManager method will automatically cause these driver
classes to be loaded.
Note that this second way of loading drivers requires a preset environment
that is persistent. If there is any doubt about that being the case, it is safer to call
the method Class.forName to explicitly load each driver. This is also the method
to use to bring in a particular driver since once the DriverManager class has been
initialized, it will never recheck the jdbc.drivers property list.
In both of the cases listed above, it is the responsibility of the newly-loaded
Driver class to register itself by calling DriverManager.registerDriver. As
mentioned above, this should be done automatically when the class is loaded.
For security reasons, the JDBC management layer will keep track of which
class loader provided which driver. Then when the DriverManager class is opening a connection, it will use only drivers that come from the local file system or
from the same class loader as the code issuing the request for a connection.
Driver classes have been loaded and registered with the DriverManager
class, they are available for establishing a connection with a database. When a
request for a connection is made with a call to the DriverManager.getConnection
method, the DriverManager tests each driver in turn to see if it can establish a connection.
It may sometimes be the case that more than one JDBC driver is capable of
connecting to a given URL. For example, when connecting to a given remote
database, it might be possible to use a JDBC-ODBC bridge driver, a JDBC-to-
generic-network-protocol driver, or a driver supplied by the database vendor. In
such cases, the order in which the drivers are tested is significant because the
DriverManager will use the first driver it finds that can successfully connect to the
given URL.
First the DriverManager tries to use each of the drivers in the order they were
registered. (The drivers listed in jdbc.drivers are always registered first.) It will
skip any drivers which are untrusted code, unless they have been loaded from the
same source as the code that is trying to open the connection.
It tests the drivers by calling the method Driver.connect on each one in turn,
passing them the URL that the user originally passed to the method DriverManager.getConnection. The first driver that recognizes the URL makes the connection.
At first glance this may seem inefficient, but it requires only a few procedure calls and string comparisons per connection since it is unlikely that dozens of drivers will be loaded concurrently.
The following code is an example of all that is normally needed to set up a connection with a driver such as a JDBC-ODBC bridge driver:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); //loads the driver
String url = "jdbc:odbc:fred";
DriverManager.getConnection(url, "userID", "passwd");