Documentation Contents |
NOTE: Some of the material in this chapter is based on JDBCtm API Tutorial and Reference, Second Edition: Universal Data Access for the Javatm 2 Platform, published by Addison Wesley as part of the Java series, ISBN 0-201-43328-1.
This appendix summarizes the new features that have been added to the JDBC API over time. Note that in order to use a feature, you must be using a driver that supports that feature.
One of the major changes in the JDBC 3.0
API is that it includes the package javax.sql
(the
JDBC Optional Package) as well as the package
java.sql
. This overview is divided into two sections,
the first giving new features introduced in the JDBC 3.0 API for
both packages, and the second giving the features introduced in the
JDBC 2.0 Optional Package. See the JDBC 3.0 API Specification for
more detailed information.
The JDBC 3.0 API introduces new material and changes in these areas:
Added the Savepoint
interface, which
contains new methods to set a savepoint, to release a savepoint,
and to roll back a transaction to a designated
savepoint.
Added the ability for deployers to control how prepared statements are pooled and reused by connections.
Defined a number of properties for theConnectionPoolDataSource
interface. These properties can be used to describe howPooledConnection
objects created byDataSource
objects should be pooled.
Added the new interface ParameterMetaData
,
which describes the number, type, and properties of parameters to
prepared statements.
Added a means of retrieving values from columns containing automatically generated values.
ResultSet
objects
Added the new methodgetMoreResults(int)
that takes an argument that specifies whetherResultSet
objects returned by aStatement
should be closed before returning any subsequentResultSet
objects.
CallableStatement
objects by
name
Added methods to allow a string to identify the
parameter to be set for a CallableStatement
object.
Added the ability to specify whether a
ResultSet
object is kept open after a transaction has
been committed.
BOOLEAN
data type
Added the data typejava.sql.Types.BOOLEAN
.BOOLEAN
is logically equivalent toBIT
.
Blob
and
Clob
objects
Added methods to allow the data contained inBlob
andClob
objects to be altered.
Ref
object
Added methods to retrieve the object referenced by aRef
object. Also added the ability to update a referenced object through theRef
object.
BLOB
,
CLOB
, ARRAY
and REF
types
Addition of theupdateBlob
,updateClob
,updateArray
, andupdateRef
methods to theResultSet
interface.
DATALINK/URL
data type
Added the data type
java.sql.Types.DATALINK
, allowing JDBC drivers to
store and retrieve references to external data.
Described the effect of transform groups and how this is reflected in the metadata.
Connector
architecture
Described the relationship between the JDBC SPI and the connector architecture.
DatabaseMetadata
APIs
Added metadata for retrieving SQL type hierarchies and various other kinds of information relating to new features.
The following features, which were
introduced in the javax.sql
package, are now part of
the JDBC 3.0 API and are included in the J2SE version 1.4:
DataSource
Object to Get a Connection
Using the JNDI API and the new
DataSource
interface, an application does not need to
specify a driver name in its code to make a connection to a data
source. It can specify a logical name that has been registered with
a JNDI naming service and retrieve a DataSource
object
that will get a connection to the desired data source. This
capability makes code more portable and much easier to
maintain.
Connection pooling allows an application to (re)use database connections that have already been established instead of always having to create new connections. Because creating and destroying database connections is expensive, this feature is important for good performance, especially for server applications.
The JDBC 2.0 Optional Package API provides hooks that allow connection pooling to be implemented on top of the JDBC driver layer. This makes it possible to have a single cache of connections available for all of the JDBC drivers in use.
The JDBC 2.0 Optional Package API allows a JDBC driver to support the standard two-phase commit protocol defined in the Java Transaction API (JTA). This means that a transaction may be distributed over multiple servers, which lets developers write enterprise applications using Enterprise JavaBeanstm components that are transactional across multiple DBMS servers.
RowSet
objects are simply
containers for tabular data that can be implemented on top of the
JDBC API. Rowsets make it possible to pass rows of data across a
network, so they are likely to be used extensively in distributed
applications. Rowsets may be very lean by being disconnected from a
data source, making it possible to display data on a thin client.
They also make it possible to use scrolling when the underlying
DBMS does not support scrollable result sets. A rowset is a
JavaBeanstm component and consequently easy to use in building an
application, especially with a development tool.
Typically, a third party will provide a
RowSet
implementation, and the application programmer
just uses it. The API for a RowSet
implementation is
generally very easy to use because most of a rowset's functionality
is inherited from the ResultSet
interface. The more
complicated aspects of a rowset take place internally and are
invisible to the application programmer. There are currently three
Early Access implementations of the RowSet
interface
available from the Java Developer Connection
(http://developer.java.sun.com/developer
).
The JDBC 2.0 core API includes the JDBC 1.0 API and adds enhancements and new functionality to it. These additions put the Java programming language at the forefront of database computing, providing both universal data access and improved performance.
Applications that use earlier versions of the JDBC API can be run using the Java 2 platform with no problem, in keeping with the goal of backward compatibility. However, an application that takes advantage of the new 2.0 features must be run with a driver that implements those features.
The new features in the JDBC 2.0 core API fall into two broad categories: support for new functionality and support for the SQL99 data types.
In addition to making the retrieval,
storage, and manipulation of data more convenient, the new features
make JDBC applications more efficient. For example, batch updates
can increase performance dramatically. The new interfaces
Blob
, Clob
, and Array
allow
applications to operate on large amounts of data without having to
materialize the data on the client, which can mean a significant
savings in transfer time and the amount of memory needed. Also, new
methods for setting the fetch size and fetch direction let a
programmer fine tune an application for more efficient data
retrieval and processing.
The JDBC 2.0 core API adds important new functionality. The following sections briefly explain each new area of functionality and summarize the supporting API.
Scrollable result sets provide the ability to move the cursor forward and backward to a specified position or to a position relative to the current position. The following interfaces have new methods that support scrollable result sets.
Statement
, PreparedStatement
, and
CallableStatement
objects that make the result sets
they produce scrollable The new batch update facility provides
the ability to send multiple updates to the database to be executed
as a batch rather than sending each update separately. The
following interfaces add methods that support batch updates, and
the exception BatchUpdateException
is new.
Programmatic updates provide the ability to make updates using the JDBC API rather than SQL statements. The following interfaces have new methods and constants that support programmatic updates.
updater
method for updating each data type
The JDBC 2.0 core API provides various other new features, which are summarized in the following list.
ResultSet
methods for getting and setting the
current fetch size and fetch direction Statement
, PreparedStatement
, and
CallableStatement
methods for getting and setting the
default fetch size and default fetch direction that result sets
generated by executing a query will have when they are first
createdgetUnicodeStream
and setUnicodeStream
methods.
ResultSet.getCharacterStream
CallableStatement.getCharacterStream
PreparedStatement.setCharacterStream
java.math.BigDecimal
values-new
versions of themethods that retrieve a
java.math.BigDecimal
value with full precision. Unlike
the deprecated versions they replace, these new versions do not
take a specified precision.
Calendar
object as a parameter, which allows the
driver to use a specified time zone rather than the default when
calculating a value for a date, time, or timestamp
The JDBC 2.0 core API adds support for using advanced data types, making it as easy to use them as it is to use simple data types. This support includes the ability to store, retrieve, and update even the new SQL data types that are essentially objects, blurring the distinction between object databases and relational databases. The next four sections ("What Are the SQL99 Data Types?" on page 145, "Summary of Support for the SQL99 Data Types" on page 146, "Mapping of the SQL99 Types" on page 148, and "SQL Locators" on page 149) describe how the JDBC 2.0 core API provides support for these advanced data types.
In addition to being able to store objects defined in SQL as values in a database table, programmers writing Java applications can also store objects defined in the Java programming language as values in a database table. The section "Support for Storing Java Objects" on page 149 describes this capability.
Note that a driver is not required to
implement functionality that its DBMS does not support, so not all
drivers necessarily implement the functionality described here.
DatabaseMetaData
methods such as
getTypeInfo
, getColumns
, and
getUDTs
may be called to get information about which
data types a driver supports.
This section briefly describes the new SQL99 data types. Their mapping to types in the Java programming language is described in section A.4.3 on page 148.
The SQL99 data types can be categorized as follows:
CHAR
, FLOAT
, DATE
, and so
on.
REF(
structured type)
-a reference to
the specified SQL structured type ARRAY[n]
-an array of n
elements that
are all one data typeCREATE TYPE
The JDBC 2.0 core API supports the SQL 99 data types by means of the following new interfaces, methods, and fields.
getter
methods in the ResultSet
interface to retrieve SQL99 type column values from a result set
getter
methods in the
CallableStatement
interface to retrieve SQL99 type
values in output parameters setter
methods in the
PreparedStatement
interface to set a SQL99 type column
value updater
methods in the ResultSet
interface to update values programmaticallyDatabaseMetaData
and
ResultSetMetaData
interfaces for getting metadata
about the SQL99 data types java.sql.Types
to support new data types and
persistent storage
The JDBC API does not try to replicate
the SQL99 types exactly; rather, its goal is to map them to types
in the Java programming language so that they retain their
functionality and are convenient to use. For example, SQL99 has
what are called locator types, which are used on a client
to designate data that is stored on a database server. Locators can
be very useful for dealing with data that is large because they
allow the data to be manipulated without having to be materialized
on the client machine. SQL99 includes locators for the types
ARRAY
, BLOB
, CLOB
and
structured types. The JDBC API does not include locators for these
types directly (and not at all for structured types) but rather
provides interfaces that are implemented such that the driver and
DBMS use the appropriate locators behind the scenes. The result is
that a developer using the JDBC API to access an SQL
ARRAY
, BLOB
, or CLOB
value
need not even be aware of locators.
The following SQL99 types are mapped to interfaces in the Java programming language:
ARRAY
-mapped to java.sql.Array
BLOB
-mapped to java.sql.Blob
CLOB
-mapped to java.sql.Clob
REF
-mapped to java.sql.Ref
Distinct types are not mapped to an
interface because they are based on a single built-in type and thus
can simply be mapped to the standard mapping for that built-in
type. For example, the following is an SQL statement that creates
the new type MONEY
.
CREATE TYPE MONEY AS NUMERIC(10, 2)
This new UDT is based on the data type
NUMERIC
, which maps to
java.math.BigDecimal
, so the type MONEY
maps to java.math.BigDecimal
. This means that a value
of type MONEY
would be retrieved with the method
getBigDecimal
, stored with the method
setBigDecimal
, and updated with the method
updateBigDecimal
.
An SQL LOCATOR
is a logical
pointer to data that resides on a database server. It typically
refers to data that is too large to materialize on the client, such
as images or audio. Locators exist only in a client environment,
and their existence is transient. A standard implementation will
use locators internally for instances of the Blob
,
Clob
, and Array
interfaces. This means
that Blob
, Clob
, and Array
objects contain a locator that points to the data on the server
rather than containing the data itself. Programmers operating on
Blob
, Clob
, and Array
instances are actually operating on the database objects they
represent. This ability to operate on large database objects
without bringing their data to the client is a major plus in
performance.
Note that the JDBC API does not call for
using the SQL LOCATOR(
structured type)
.
In a standard implementation, a Struct
object contains
the data of the structured type that it maps and is not implemented
internally as a locator, as are Blob
,
Clob
, and Array
objects.
The JDBC API has always supported
persistent storage of objects defined in the Java programming
language through the methods getObject
and
setObject
. But, of course, persistent storage of Java
objects does not actually occur unless a DBMS also supports it. Up
to this point, support was limited, but a new generation of DBMSs
that recognize Java objects as a data type is emerging. In these
DBMSs, termed Java relational DBMSs, an instance of a Java class
can be stored as a column value in a database table.
Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
Java Technology |