|Contents | Prev | Next||JDBCTM Guide: Getting Started|
The DriverManager.getConnection method takes a URL string as an argument. The JDBC management layer will attempt to locate a driver that can connect to the database represented by the URL. The JDBC management layer does this by asking each driver in turn (see Section 6.2 below) if it can connect to the given URL.1 Drivers should examine the URL to see if it specifies a subprotocol that they support (see Section 6.3 below), and if so, they should attempt to connect to the specified database. If they succeed in establishing a connection, then they should return an appropriate java.sql.Connection object.
From the java.sql.Connection object it is possible to obtain java.sql.Statement, java.sql.PreparedStatement , and java.sql.CallableStatement objects that can be used to execute SQL statement s.
We also permit applications to bypass the JDBC management layer during connection open and explicitly select and use a particular driver.
JDBC allows users to specify a driver list by setting a Java property "jdbc.drivers". If this property is defined,then it should be a colon separated list of driver class names, such as "acme.wonder.Driver :foobaz.openNet.Driver:vendor.OurDriver".
When searching for a driver, JDBC will use the first driver it finds that can successfully connect to the given URL. It will first try to use each of the drivers specified in the sql.drivers list, in the order given. It will then proceed to try to use each loaded driver in the order in which the drivers were loaded. 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 (see the security discussion in Section 5).
We would like this JDBC naming mechanism to have the following properties:
We recommend that JDBC URL's be structured as:
where a subprotocol names a particular kind of database connectivity mechanism that may be supported by one or more drivers. The contents and syntax of the subname will depend on the subprotocol.
If you are specifying a network address as part of your subname, we recommend following the standard URL naming convention of "//hostname:port/subsubname" for the subname. The subsubname can have arbitrary internal syntax.
In this example the subprotocol is "odbc" and the subname is a local ODBC data source name "fred". A JDBC-ODBC driver can check for URLs that have subprotocol "odbc" and then use the subname in an ODBC SQLConnect.
If you are using some generic database connectivity protocol "dbnet" to talk to a database listener , you might have a URL like:
In this example the URL specifies that we should use the "dbnet" protocol to connect to port 356 on host wombat and then present the subsubname "fred" to that port to locate the final database.
If you wish to use some network name service to provide a level of indirection in database names, then we recommend using the name of the naming service as the subprotocol. So for example one might have a URL like:
In this example, the URL specifies that we should use the local DCE naming service to resolve the database name "accounts-payable" into a more specific name that can be used to connect to the real database. In some situations, it might be appropriate to provide a pseudo driver that performed a name lookup via a network name server and then used the resulting information to locate the real driver and do the real connection open.
The full odbc subprotocol URL syntax is:
Thus valid jdbc:odbc names include:
In order to allow applets to access databases in a generic way, we recommend that as much connection information as possible be encoded as part of the URL and that driver writers minimize their use of property sets.
First, when the JDBC java.sql.DriverManager class initializes it will look for a "sql.drivers" property in the system properties. If the property exists it should consist of a colon-separated list of driver class names. Each of the named classes should implement the java.sql.Driver interface. The DriverManager class will attempt to load each named Driver class.
Second, a programmer can explicitly load a driver class using the standard Class.forName method. For example, to load the acme.db.Driver class you might do:
In both cases it is the responsibility of each newly loaded Driver class to register itself with the DriverManager, using the DriverManager.registerDriver method. This will allow the DriverManager to use the driver when it is attempting to make database connections.
For security reasons the JDBC management layer will keep track of which class loader provided which driver and when opening connections it will only use drivers that come from the local filesystem or from the same classloader as the code issuing the getConnection request.
email@example.com or firstname.lastname@example.org Copyright © 1996, 1997 Sun Microsystems, Inc. All rights reserved.