Chapter 13: JDBC Connectivity In JDBC programming, developers
Chapter 13: JDBC Connectivity In JDBC programming, developers typically perform the following steps: 1. Obtain a connection to the remote database server (in JDBC 1. x, it is necessary to instantiate a database driver prior to obtaining a connection). 2. Create and prepare an SQL statement for execution (or call a stored procedure in the RDBMS). 3. Execute the SQL statement. 4. Obtain the returned result set (if any) and work on it. 5. Disconnect from the remote database. Administrators are most interested in facilitating the first step obtaining a connection to the desired database. Establishing and Terminating Connections to RDBMS s Other than providing a unified way of accessing, modifying, and manipulating data in RDBMSs, JDBC also provides a unified way to connect to RDBMSs from different vendors. While normal native connections to Oracle will be very different from connections to MySQL (which will be different from working with Microsoft s SQL server), connecting to any of these RDBMSs can be accomplished using the same JDBC API calls. Evolving JDBC Versions In the early days of JDBC, most Java developers were coding to the JDBC 1 standard. Under this standard, all code that needed to establish a connection to an RDBMS (as well as the code to disconnect from the RDBMS) was written by the developers. In fact, even the code to select and activate a JDBC driver was coded by the developers. While simple and straightforward to code, this approach created a problem; in some cases where the driver used was hard-coded by the developers, the code to obtain a connection worked only with RDBMSs from a specific vendor. With the arrival of JDBC 2, this restriction was relaxed. JDBC 2 introduced the concept of a data source. This is an indirect way of specifying the JDBC driver to be used for making the connection. Developers can now obtain a connection from the data source in their code, enabling the same JDBC code to work with drivers from any vendor. Meanwhile, an administrator can switch database vendor support by simply configuring a different data source, and no code changes are needed. The selection and configuration of data sources shifted from the developer to the administrator. As Web applications became more complex, the demand for high-performance concurrent access to database connections increased. The code that developers write to maintain and share database connections becomes highly complex and error-prone. Because this code is utilitarian, and can be used by all applications, it is another area that JDBC 2 attempts to improve on (see the section Database Connection Pooling, later in this chapter). While JDBC 2 s introduction of data source and connection pooling support opens up new possibilities for RDBMS developers, it falls short of specifying standard ways in which these features should (or must) be used. As a result, many of the architectural issues are left for the JDBC driver writers to
For high quality java hosting services please check java web hosting website.