ojluni/src/main/java/javax/sql/package.html - platform/libcore.git - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <html>
 <head>
 <!--
 Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights reserved.
 DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

 This code is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License version 2 only, as
 published by the Free Software Foundation.  Oracle designates this
 particular file as subject to the "Classpath" exception as provided
 by Oracle in the LICENSE file that accompanied this code.

 This code is distributed in the hope that it will be useful, but WITHOUT
 ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 version 2 for more details (a copy is included in the LICENSE file that
 accompanied this code).

 You should have received a copy of the GNU General Public License version
 2 along with this work; if not, write to the Free Software Foundation,
 Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

 Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 or visit www.oracle.com if you need additional information or have any
 questions.
 -->

 </head>


 <body bgcolor="white">

 Provides the API for server side data source access and processing from
 the Java<sup><font size=-2>TM</font></sup> programming language.
 This package supplements the <code>java.sql</code>
 package and, as of the version 1.4 release, is included in the
 Java Platform, Standard Edition
 (Java SE<sup><font size=-2>TM</sup></font>).
 It remains an essential part of the Java Platform, Enterprise Edition
 (Java EE<sup><font size=-2>TM</sup></font>).
 <P>
 The <code>javax.sql</code> package provides for the following:
 <OL>
   <LI>The <code>DataSource</code> interface as an alternative to the
       <code>DriverManager</code> for establishing a
       connection with a data source
   <LI>Connection pooling and Statement pooling
   <LI>Distributed transactions
   <LI>Rowsets
 </OL>
 <P>
 Applications use the <code>DataSource</code> and <code>RowSet</code>
 APIs directly, but the connection pooling and distributed transaction
 APIs are used internally by the middle-tier infrastructure.

 <H2>Using a <code>DataSource</code> Object to Make a Connection</H2>

 The <code>javax.sql</code> package provides the preferred
 way to make a connection with a data source.  The <code>DriverManager</code>
 class, the original mechanism, is still valid, and code using it will
 continue to run.  However, the newer <code>DataSource</code> mechanism
 is preferred because it offers many advantages over the
 <code>DriverManager</code> mechanism.
 <P>
 These are the main advantages of using a <code>DataSource</code> object to
 make a connection:
 <UL>

   <LI>Changes can be made to a data source's properties, which means
       that it is not necessary to make changes in application code when
       something about the data source or driver changes.
   <LI>Connection  and Statement pooling and distributed transactions are available
       through a <code>DataSource</code> object that is
       implemented to work with the middle-tier infrastructure.
       Connections made through the <code>DriverManager</code>
       do not have connection and statement pooling or distributed transaction
       capabilities.
 </UL>
 <P>
 Driver vendors provide <code>DataSource</code> implementations. A
 particular <code>DataSource</code> object represents a particular
 physical data source, and each connection the <code>DataSource</code> object
 creates is a connection to that physical data source.
 <P>
 A logical name for the data source is registered with a naming service that
 uses the Java Naming and Directory Interface<sup><font size=-2>TM</font></sup>
 (JNDI) API, usually by a system administrator or someone performing the
 duties of a system administrator. An application can retrieve the
 <code>DataSource</code> object it wants by doing a lookup on the logical
 name that has been registered for it.  The application can then use the
 <code>DataSource</code> object to create a connection to the physical data
 source it represents.
 <P>
 A <code>DataSource</code> object can be implemented to work with the
 middle tier infrastructure so that the connections it produces will be
 pooled for reuse. An application that uses such a <code>DataSource</code>
 implementation will automatically get a connection that participates in
 connection pooling.
 A <code>DataSource</code> object can also be implemented to work with the
 middle tier infrastructure so that the connections it produces can be
 used for distributed transactions without any special coding.

 <H2>Connection Pooling and Statement Pooling</H2>

 Connections made via a <code>DataSource</code>
 object that is implemented to work with a middle tier connection pool manager
 will participate in connection pooling.  This can improve performance
 dramatically because creating new connections is very expensive.
 Connection pooling allows a connection to be used and reused,
 thus cutting down substantially on the number of new connections
 that need to be created.
 <P>
 Connection pooling is totally transparent.  It is done automatically
 in the middle tier of a Java EE configuration, so from an application's
 viewpoint, no change in code is required. An application simply uses
 the <code>DataSource.getConnection</code> method to get the pooled
 connection and uses it the same way it uses any <code>Connection</code>
 object.
 <P>
 The classes and interfaces used for connection pooling are:
 <UL>
   <LI><code>ConnectionPoolDataSource</code>
   <LI><code>PooledConnection</code>
   <LI><code>ConnectionEvent</code>
   <LI><code>ConnectionEventListener</code>
    <LI><code>StatementEvent</code>
   <LI><code>StatementEventListener</code>
 </UL>
 The connection pool manager, a facility in the middle tier of
 a three-tier architecture, uses these classes and interfaces
 behind the scenes.  When a <code>ConnectionPoolDataSource</code> object
 is called on to create a <code>PooledConnection</code> object, the
 connection pool manager will register as a <code>ConnectionEventListener</code>
 object with the new <code>PooledConnection</code> object.  When the connection
 is closed or there is an error, the connection pool manager (being a listener)
 gets a notification that includes a <code>ConnectionEvent</code> object.
 <p>
 If the connection pool manager supports <code>Statement</code> pooling, for
 <code>PreparedStatements</code>, which can be determined by invoking the method
 <code>DatabaseMetaData.supportsStatementPooling</code>,  the
 connection pool manager will register as a <code>StatementEventListener</code>
 object with the new <code>PooledConnection</code> object.  When the
 <code>PreparedStatement</code> is closed or there is an error, the connection
 pool manager (being a listener)
 gets a notification that includes a <code>StatementEvent</code> object.
 <p>

 <H2>Distributed Transactions</H2>

 As with pooled connections, connections made via a <code>DataSource</code>
 object that is implemented to work with the middle tier infrastructure
 may participate in distributed transactions.  This gives an application
 the ability to involve data sources on multiple servers in a single
 transaction.
 <P>
 The classes and interfaces used for distributed transactions are:
 <UL>
   <LI><code>XADataSource</code>
   <LI><code>XAConnection</code>
 </UL>
 These interfaces are used by the transaction manager; an application does
 not use them directly.
 <P>
 The <code>XAConnection</code> interface is derived from the
 <code>PooledConnection</code> interface, so what applies to a pooled connection
 also applies to a connection that is part of a distributed transaction.
 A transaction manager in the middle tier handles everything transparently.
 The only change in application code is that an application cannot do anything
 that would interfere with the transaction manager's handling of the transaction.
 Specifically, an application cannot call the methods <code>Connection.commit</code>
 or <code>Connection.rollback</code>, and it cannot set the connection to be in
 auto-commit mode (that is, it cannot call
 <code>Connection.setAutoCommit(true)</code>).
 <P>
 An application does not need to do anything special to participate in a
 distributed transaction.
 It simply creates connections to the data sources it wants to use via
 the <code>DataSource.getConnection</code> method, just as it normally does.
 The transaction manager manages the transaction behind the scenes.  The
 <code>XADataSource</code> interface creates <code>XAConnection</code> objects, and
 each <code>XAConnection</code> object creates an <code>XAResource</code> object
 that the transaction manager uses to manage the connection.


 <H2>Rowsets</H2>
 The <code>RowSet</code> interface works with various other classes and
 interfaces behind the scenes. These can be grouped into three categories.
 <OL>
 <LI>Event Notification
 <UL>
   <LI><code>RowSetListener</code><br>
 A <code>RowSet</code> object is a JavaBeans<sup><font size=-2>TM</font></sup>
 component because it has properties and participates in the JavaBeans
 event notification mechanism. The <code>RowSetListener</code> interface
 is implemented by a component that wants to be notified about events that
 occur to a particular <code>RowSet</code> object.  Such a component registers
 itself as a listener with a rowset via the <code>RowSet.addRowSetListener</code>
 method.
 <P>
 When the <code>RowSet</code> object changes one of its rows, changes all of
 it rows, or moves its cursor, it also notifies each listener that is registered
 with it.  The listener reacts by carrying out its implementation of the
 notification method called on it.
 <P>
   <LI><code>RowSetEvent</code><br>
 As part of its internal notification process, a <code>RowSet</code> object
 creates an instance of <code>RowSetEvent</code> and passes it to the listener.
 The listener can use this <code>RowSetEvent</code> object to find out which rowset
 had the event.
 </UL>
 <P>
 <LI>Metadata
 <UL>
   <LI><code>RowSetMetaData</code><br>
 This interface, derived from the
 <code>ResultSetMetaData</code> interface, provides information about
 the columns in a <code>RowSet</code> object.  An application can use
 <code>RowSetMetaData</code> methods to find out how many columns the
 rowset contains and what kind of data each column can contain.
 <P>
 The <code>RowSetMetaData</code> interface provides methods for
 setting the information about columns, but an application would not
 normally use these methods.  When an application calls the <code>RowSet</code>
 method <code>execute</code>, the <code>RowSet</code> object will contain
 a new set of rows, and its <code>RowSetMetaData</code> object will have been
 internally updated to contain information about the new columns.
 <P>
 </UL>
 <LI>The Reader/Writer Facility<br>
 A <code>RowSet</code> object that implements the <code>RowSetInternal</code>
 interface can call on the <code>RowSetReader</code> object associated with it
 to populate itself with data.  It can also call on the <code>RowSetWriter</code>
 object associated with it to write any changes to its rows back to the
 data source from which it originally got the rows.
 A rowset that remains connected to its data source does not need to use a
 reader and writer because it can simply operate on the data source directly.

 <UL>
   <LI><code>RowSetInternal</code><br>
 By implementing the <code>RowSetInternal</code> interface, a
 <code>RowSet</code> object gets access to
 its internal state and is able to call on its reader and writer. A rowset
 keeps track of the values in its current rows and of the values that immediately
 preceded the current ones, referred to as the <i>original</i> values.  A rowset
 also keeps track of (1) the parameters that have been set for its command and
 (2) the connection that was passed to it, if any.  A rowset uses the
 <code>RowSetInternal</code> methods behind the scenes to get access to
 this information.  An application does not normally invoke these methods directly.
 <P>
   <LI><code>RowSetReader</code><br>
 A disconnected <code>RowSet</code> object that has implemented the
 <code>RowSetInternal</code> interface can call on its reader (the
 <code>RowSetReader</code> object associated with it) to populate it with
 data.  When an application calls the <code>RowSet.execute</code> method,
 that method calls on the rowset's reader to do much of the work. Implementations
 can vary widely, but generally a reader makes a connection to the data source,
 reads data from the data source and populates the rowset with it, and closes
 the connection. A reader may also update the <code>RowSetMetaData</code> object
 for its rowset.  The rowset's internal state is also updated, either by the
 reader or directly by the method <code>RowSet.execute</code>.


   <LI><code>RowSetWriter</code><br>
 A disconnected <code>RowSet</code> object that has implemented the
 <code>RowSetInternal</code> interface can call on its writer (the
 <code>RowSetWriter</code> object associated with it) to write changes
 back to the underlying data source.  Implementations may vary widely, but
 generally, a writer will do the following:

 <P>
 <UL>
   <LI>Make a connection to the data source
   <LI>Check to see whether there is a conflict, that is, whether
       a value that has been changed in the rowset has also been changed
       in the data source
   <LI>Write the new values to the data source if there is no conflict
   <LI>Close the connection
 </UL>


 </UL>
 </OL>
 <P>
 The <code>RowSet</code> interface may be implemented in any number of
 ways, and anyone may write an implementation. Developers are encouraged
 to use their imaginations in coming up with new ways to use rowsets.
 <P>
 <B>IMPORTANT NOTE:</B> Code that uses API marked "Since 1.6" must be run using a
 JDBC technology driver that implements the JDBC 4.0 API.
 You must check your driver documentation to be sure that it implements
 the particular features you want to use.
 <P>

 <h2>Package Specification</h2>

 <ul>
   <li><a href="http://java.sun.com/products/jdbc/download.html">Specification of the
       JDBC 4.0 API</a>
 </ul>

 <h2>Related Documentation</h2>

 The Java Series book published by Addison-Wesley Longman provides detailed
 information about the classes and interfaces in the <code>javax.sql</code>
 package:

 <ul>
   <li><a href="http://java.sun.com/docs/books/jdbc"><i>JDBC<sup><font size=-2>TM</font></sup>
       API Tutorial and Reference, Third Edition:</i></a>
 </ul>
 <P>
 @since 1.4
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
	<html>
	<head>
	<!--
	Copyright (c) 2000, 2006, Oracle and/or its affiliates. All rights reserved.
	DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

	This code is free software; you can redistribute it and/or modify it
	under the terms of the GNU General Public License version 2 only, as
	published by the Free Software Foundation. Oracle designates this
	particular file as subject to the "Classpath" exception as provided
	by Oracle in the LICENSE file that accompanied this code.

	This code is distributed in the hope that it will be useful, but WITHOUT
	ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
	FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
	version 2 for more details (a copy is included in the LICENSE file that
	accompanied this code).

	You should have received a copy of the GNU General Public License version
	2 along with this work; if not, write to the Free Software Foundation,
	Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

	Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
	or visit www.oracle.com if you need additional information or have any
	questions.
	-->

	</head>



	<body bgcolor="white">

	Provides the API for server side data source access and processing from
	the Java<sup><font size=-2>TM</font></sup> programming language.
	This package supplements the <code>java.sql</code>
	package and, as of the version 1.4 release, is included in the
	Java Platform, Standard Edition
	(Java SE<sup><font size=-2>TM</sup></font>).
	It remains an essential part of the Java Platform, Enterprise Edition
	(Java EE<sup><font size=-2>TM</sup></font>).
	<P>
	The <code>javax.sql</code> package provides for the following:
	<OL>
	<LI>The <code>DataSource</code> interface as an alternative to the
	<code>DriverManager</code> for establishing a
	connection with a data source
	<LI>Connection pooling and Statement pooling
	<LI>Distributed transactions
	<LI>Rowsets
	</OL>
	<P>
	Applications use the <code>DataSource</code> and <code>RowSet</code>
	APIs directly, but the connection pooling and distributed transaction
	APIs are used internally by the middle-tier infrastructure.

	<H2>Using a <code>DataSource</code> Object to Make a Connection</H2>

	The <code>javax.sql</code> package provides the preferred
	way to make a connection with a data source. The <code>DriverManager</code>
	class, the original mechanism, is still valid, and code using it will
	continue to run. However, the newer <code>DataSource</code> mechanism
	is preferred because it offers many advantages over the
	<code>DriverManager</code> mechanism.
	<P>
	These are the main advantages of using a <code>DataSource</code> object to
	make a connection:
	<UL>

	<LI>Changes can be made to a data source's properties, which means
	that it is not necessary to make changes in application code when
	something about the data source or driver changes.
	<LI>Connection and Statement pooling and distributed transactions are available
	through a <code>DataSource</code> object that is
	implemented to work with the middle-tier infrastructure.
	Connections made through the <code>DriverManager</code>
	do not have connection and statement pooling or distributed transaction
	capabilities.
	</UL>
	<P>
	Driver vendors provide <code>DataSource</code> implementations. A
	particular <code>DataSource</code> object represents a particular
	physical data source, and each connection the <code>DataSource</code> object
	creates is a connection to that physical data source.
	<P>
	A logical name for the data source is registered with a naming service that
	uses the Java Naming and Directory Interface<sup><font size=-2>TM</font></sup>
	(JNDI) API, usually by a system administrator or someone performing the
	duties of a system administrator. An application can retrieve the
	<code>DataSource</code> object it wants by doing a lookup on the logical
	name that has been registered for it. The application can then use the
	<code>DataSource</code> object to create a connection to the physical data
	source it represents.
	<P>
	A <code>DataSource</code> object can be implemented to work with the
	middle tier infrastructure so that the connections it produces will be
	pooled for reuse. An application that uses such a <code>DataSource</code>
	implementation will automatically get a connection that participates in
	connection pooling.
	A <code>DataSource</code> object can also be implemented to work with the
	middle tier infrastructure so that the connections it produces can be
	used for distributed transactions without any special coding.

	<H2>Connection Pooling and Statement Pooling</H2>

	Connections made via a <code>DataSource</code>
	object that is implemented to work with a middle tier connection pool manager
	will participate in connection pooling. This can improve performance
	dramatically because creating new connections is very expensive.
	Connection pooling allows a connection to be used and reused,
	thus cutting down substantially on the number of new connections
	that need to be created.
	<P>
	Connection pooling is totally transparent. It is done automatically
	in the middle tier of a Java EE configuration, so from an application's
	viewpoint, no change in code is required. An application simply uses
	the <code>DataSource.getConnection</code> method to get the pooled
	connection and uses it the same way it uses any <code>Connection</code>
	object.
	<P>
	The classes and interfaces used for connection pooling are:
	<UL>
	<LI><code>ConnectionPoolDataSource</code>
	<LI><code>PooledConnection</code>
	<LI><code>ConnectionEvent</code>
	<LI><code>ConnectionEventListener</code>
	<LI><code>StatementEvent</code>
	<LI><code>StatementEventListener</code>
	</UL>
	The connection pool manager, a facility in the middle tier of
	a three-tier architecture, uses these classes and interfaces
	behind the scenes. When a <code>ConnectionPoolDataSource</code> object
	is called on to create a <code>PooledConnection</code> object, the
	connection pool manager will register as a <code>ConnectionEventListener</code>
	object with the new <code>PooledConnection</code> object. When the connection
	is closed or there is an error, the connection pool manager (being a listener)
	gets a notification that includes a <code>ConnectionEvent</code> object.
	<p>
	If the connection pool manager supports <code>Statement</code> pooling, for
	<code>PreparedStatements</code>, which can be determined by invoking the method
	<code>DatabaseMetaData.supportsStatementPooling</code>, the
	connection pool manager will register as a <code>StatementEventListener</code>
	object with the new <code>PooledConnection</code> object. When the
	<code>PreparedStatement</code> is closed or there is an error, the connection
	pool manager (being a listener)
	gets a notification that includes a <code>StatementEvent</code> object.
	<p>

	<H2>Distributed Transactions</H2>

	As with pooled connections, connections made via a <code>DataSource</code>
	object that is implemented to work with the middle tier infrastructure
	may participate in distributed transactions. This gives an application
	the ability to involve data sources on multiple servers in a single
	transaction.
	<P>
	The classes and interfaces used for distributed transactions are:
	<UL>
	<LI><code>XADataSource</code>
	<LI><code>XAConnection</code>
	</UL>
	These interfaces are used by the transaction manager; an application does
	not use them directly.
	<P>
	The <code>XAConnection</code> interface is derived from the
	<code>PooledConnection</code> interface, so what applies to a pooled connection
	also applies to a connection that is part of a distributed transaction.
	A transaction manager in the middle tier handles everything transparently.
	The only change in application code is that an application cannot do anything
	that would interfere with the transaction manager's handling of the transaction.
	Specifically, an application cannot call the methods <code>Connection.commit</code>
	or <code>Connection.rollback</code>, and it cannot set the connection to be in
	auto-commit mode (that is, it cannot call
	<code>Connection.setAutoCommit(true)</code>).
	<P>
	An application does not need to do anything special to participate in a
	distributed transaction.
	It simply creates connections to the data sources it wants to use via
	the <code>DataSource.getConnection</code> method, just as it normally does.
	The transaction manager manages the transaction behind the scenes. The
	<code>XADataSource</code> interface creates <code>XAConnection</code> objects, and
	each <code>XAConnection</code> object creates an <code>XAResource</code> object
	that the transaction manager uses to manage the connection.


	<H2>Rowsets</H2>
	The <code>RowSet</code> interface works with various other classes and
	interfaces behind the scenes. These can be grouped into three categories.
	<OL>
	<LI>Event Notification
	<UL>
	<LI><code>RowSetListener</code><br>
	A <code>RowSet</code> object is a JavaBeans<sup><font size=-2>TM</font></sup>
	component because it has properties and participates in the JavaBeans
	event notification mechanism. The <code>RowSetListener</code> interface
	is implemented by a component that wants to be notified about events that
	occur to a particular <code>RowSet</code> object. Such a component registers
	itself as a listener with a rowset via the <code>RowSet.addRowSetListener</code>
	method.
	<P>
	When the <code>RowSet</code> object changes one of its rows, changes all of
	it rows, or moves its cursor, it also notifies each listener that is registered
	with it. The listener reacts by carrying out its implementation of the
	notification method called on it.
	<P>
	<LI><code>RowSetEvent</code><br>
	As part of its internal notification process, a <code>RowSet</code> object
	creates an instance of <code>RowSetEvent</code> and passes it to the listener.
	The listener can use this <code>RowSetEvent</code> object to find out which rowset
	had the event.
	</UL>
	<P>
	<LI>Metadata
	<UL>
	<LI><code>RowSetMetaData</code><br>
	This interface, derived from the
	<code>ResultSetMetaData</code> interface, provides information about
	the columns in a <code>RowSet</code> object. An application can use
	<code>RowSetMetaData</code> methods to find out how many columns the
	rowset contains and what kind of data each column can contain.
	<P>
	The <code>RowSetMetaData</code> interface provides methods for
	setting the information about columns, but an application would not
	normally use these methods. When an application calls the <code>RowSet</code>
	method <code>execute</code>, the <code>RowSet</code> object will contain
	a new set of rows, and its <code>RowSetMetaData</code> object will have been
	internally updated to contain information about the new columns.
	<P>
	</UL>
	<LI>The Reader/Writer Facility<br>
	A <code>RowSet</code> object that implements the <code>RowSetInternal</code>
	interface can call on the <code>RowSetReader</code> object associated with it
	to populate itself with data. It can also call on the <code>RowSetWriter</code>
	object associated with it to write any changes to its rows back to the
	data source from which it originally got the rows.
	A rowset that remains connected to its data source does not need to use a
	reader and writer because it can simply operate on the data source directly.

	<UL>
	<LI><code>RowSetInternal</code><br>
	By implementing the <code>RowSetInternal</code> interface, a
	<code>RowSet</code> object gets access to
	its internal state and is able to call on its reader and writer. A rowset
	keeps track of the values in its current rows and of the values that immediately
	preceded the current ones, referred to as the <i>original</i> values. A rowset
	also keeps track of (1) the parameters that have been set for its command and
	(2) the connection that was passed to it, if any. A rowset uses the
	<code>RowSetInternal</code> methods behind the scenes to get access to
	this information. An application does not normally invoke these methods directly.
	<P>
	<LI><code>RowSetReader</code><br>
	A disconnected <code>RowSet</code> object that has implemented the
	<code>RowSetInternal</code> interface can call on its reader (the
	<code>RowSetReader</code> object associated with it) to populate it with
	data. When an application calls the <code>RowSet.execute</code> method,
	that method calls on the rowset's reader to do much of the work. Implementations
	can vary widely, but generally a reader makes a connection to the data source,
	reads data from the data source and populates the rowset with it, and closes
	the connection. A reader may also update the <code>RowSetMetaData</code> object
	for its rowset. The rowset's internal state is also updated, either by the
	reader or directly by the method <code>RowSet.execute</code>.


	<LI><code>RowSetWriter</code><br>
	A disconnected <code>RowSet</code> object that has implemented the
	<code>RowSetInternal</code> interface can call on its writer (the
	<code>RowSetWriter</code> object associated with it) to write changes
	back to the underlying data source. Implementations may vary widely, but
	generally, a writer will do the following:

	<P>
	<UL>
	<LI>Make a connection to the data source
	<LI>Check to see whether there is a conflict, that is, whether
	a value that has been changed in the rowset has also been changed
	in the data source
	<LI>Write the new values to the data source if there is no conflict
	<LI>Close the connection
	</UL>


	</UL>
	</OL>
	<P>
	The <code>RowSet</code> interface may be implemented in any number of
	ways, and anyone may write an implementation. Developers are encouraged
	to use their imaginations in coming up with new ways to use rowsets.
	<P>
	<B>IMPORTANT NOTE:</B> Code that uses API marked "Since 1.6" must be run using a
	JDBC technology driver that implements the JDBC 4.0 API.
	You must check your driver documentation to be sure that it implements
	the particular features you want to use.
	<P>

	<h2>Package Specification</h2>

	<ul>
	<li><a href="http://java.sun.com/products/jdbc/download.html">Specification of the
	JDBC 4.0 API</a>
	</ul>

	<h2>Related Documentation</h2>

	The Java Series book published by Addison-Wesley Longman provides detailed
	information about the classes and interfaces in the <code>javax.sql</code>
	package:

	<ul>
	<li><a href="http://java.sun.com/docs/books/jdbc"><i>JDBC<sup><font size=-2>TM</font></sup>
	API Tutorial and Reference, Third Edition:</i></a>
	</ul>
	<P>
	@since 1.4
	</body>
	</html>