< prev index next >
src/java.sql.rowset/share/classes/com/sun/rowset/providers/package-info.java
Print this page
rev 52981 : 8215309: Convert package.html files to package-info.java files
Reviewed-by:
*** 1,170 ****
! <!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en">
! <html>
! <head>
!
! <meta http-equiv="Content-Type"
! content="text/html; charset=iso-8859-1">
!
! <meta name="GENERATOR"
! content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]">
! <!--
!
! Copyright (c) 2003, 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.
! -->
! <title>javax.sql.rowset.providers Package</title>
! </head>
! <body bgcolor="#ffffff">
! Repository for the <code>RowSet</code> reference implementations of the
! <code>SyncProvider</code> abstract class. These implementations provide a
! disconnected <code>RowSet</code>
! object with the ability to synchronize the data in the underlying data
! source with its data. These implementations are provided as
! the default <code>SyncProvider</code> implementations and are accessible via the
! <code>SyncProvider</code> SPI managed by the <code>SyncFactory</code>.
!
! <h3>1.0 <code>SyncProvider</code> Reference Implementations</h3>
! The main job of a <code>SyncProvider</code> implementation is to manage
! the reader and writer mechanisms.
! The <code>SyncProvider</code> SPI, as specified in the <code>javax.sql.rowset.spi</code>
! package, provides a pluggable mechanism by which <code>javax.sql.RowSetReader</code>
! and <code>javax.sql.RowSetWriter</code> implementations can be supplied to a disconnected
! <code>RowSet</code> object.
! <P>
! A reader, a <code>javax.sql.RowSetReader</code>
! object, does the work necessary to populate a <code>RowSet</code> object with data.
! A writer, a <code>javax.sql.RowSetWriter</code> object, does the work necessary for
! synchronizing a <code>RowSet</code> object's data with the data in the originating
! source of data. Put another way, a writer writes a <code>RowSet</code>
! object's data back to the data source.
! <P>
! Generally speaking, the course of events is this. The reader makes a connection to
! the data source and reads the data from a <code>ResultSet</code> object into its
! <code>RowSet</code> object. Then it closes the connection. While
! the <code>RowSet</code> object is disconnected, an application makes some modifications
! to the data and calls the method <code>acceptChanges</code>. At this point, the
! writer is called to write the changes back to the database table or view
! from which the original data came. This is called <i>synchronization</i>.
! <P>
! If the data in the originating data source has not changed, there is no problem
! with just writing the <code>RowSet</code> object's new data to the data source.
! If it has changed, however, there is a conflict that needs to be resolved. One
! way to solve the problem is not to let the data in the data source be changed in
! the first place, which can be done by setting locks on a row, a table, or the
! whole data source. Setting locks is a way to avoid conflicts, but it can be
! very expensive. Another approach, which is at the other end of the spectrum,
! is simply to assume that no conflicts will occur and thus do nothing to avoid
! conflicts.
! Different <code>SyncProvider</code> implementations may handle synchronization in
! any of these ways, varying from doing no checking for
! conflicts, to doing various levels of checking, to guaranteeing that there are no
! conflicts.
! <P>
! The <code>SyncProvider</code> class offers methods to help a <code>RowSet</code>
! object discover and manage how a provider handles synchronization.
! The method <code>getProviderGrade</code> returns the
! grade of synchronization a provider offers. An application can
! direct the provider to use a particular level of locking by calling
! the method <code>setDataSourceLock</code> and specifying the level of locking desired.
! If a <code>RowSet</code> object's data came from an SQL <code>VIEW</code>, an
! application may call the method <code>supportsUpdatableView</code> to
! find out whether the <code>VIEW</code> can be updated.
! <P>
! Synchronization is done completely behind the scenes, so it is third party vendors of
! synchronization provider implementations who have to take care of this complex task.
! Application programmers can decide which provider to use and the level of locking to
! be done, but they are free from having to worry about the implementation details.
! <P>
! The JDBC <code>RowSet</code> Implementations reference implementation provides two
! implementations of the <code>SyncProvider</code> class:
!
! <UL>
! <LI>
! <b><code>RIOptimisticProvider</code></b> - provides the <code>javax.sql.RowSetReader</code>
! and <code>javax.sql.RowSetWriter</code> interface implementations and provides
! an optimistic concurrency model for synchronization. This model assumes that there
! will be few conflicts and therefore uses a relatively low grade of synchronization.
! If no other provider is available, this is the default provider that the
! <code>SyncFactory</code> will supply to a <code>RowSet</code> object.
! <br>
! <LI>
! <b><code>RIXMLProvider</code></b> - provides the <code>XmlReader</code> (an extension
! of the <code>javax.sql.RowSetReader</code> interface) and the <code>XmlWriter</code>
! (an extension of the <code>javax.sql.RowSetWriter</code> interface) to enable
! <code>WebRowSet</code> objects to write their state to a
! well formed XML document according to the <code>WebRowSet</code> XML schema
! definition.<br>
! </UL>
!
! <h3>2.0 Basics in RowSet Population & Synchronization</h3>
! A rowset's first task is to populate itself with rows of column values.
! Generally, these rows will come from a relational database, so a rowset
! has properties that supply what is necessary for making a connection to
! a database and executing a query. A rowset that does not need to establish
! a connection and execute a command, such as one that gets its data from
! a tabular file instead of a relational database, does not need to have these
! properties set. The vast majority of RowSets, however, do need to set these
! properties. The general rule is that a RowSet is required to set only the
! properties that it uses.<br>
! <br>
! The <code>command</code> property contains the query that determines what
! data a <code>RowSet</code> will contain. Rowsets have methods for setting a query's
! parameter(s), which means that a query can be executed multiple times with
! different parameters to produce different result sets. Or the query can be
! changed to something completely new to get a new result set.
! <p>Once a rowset contains the rows from a <code>ResultSet</code> object or some
! other data source, its column values can be updated, and its rows can be
! inserted or deleted. Any method that causes a change in the rowset's values
! or cursor position also notifies any object that has been registered as
! a listener with the rowset. So, for example, a table that displays the rowset's
! data in an applet can be notified of changes and make updates as they
! occur.<br>
! <br>
! The changes made to a rowset can be propagated back to the original data
! source to keep the rowset and its data source synchronized. Although this
! involves many operations behind the scenes, it is completely transparent
! to the application programmer and remains the concern of the RowSet provider
! developer. All an application has to do is invoke the method <code>acceptChanges</code>,
! and the data source backing the rowset will be updated to match the current
! values in the rowset. </p>
!
! <p>A disconnected rowset, such as a <code>CachedRowSet</code> or <code>WebRowSet</code>
! object, establishes a connection to populate itself with data from a database
! and then closes the connection. The <code>RowSet</code> object will remain
! disconnected until it wants to propagate changes back to its database table,
! which is optional. To write its changes back to the database (synchronize with
! the database), the rowset establishes a connection, write the changes, and then
! once again disconnects itself.<br>
! </p>
!
! <h3> 3.0 Other Possible Implementations</h3>
! There are many other possible implementations of the <code>SyncProvider</code> abstract
! class. One possibility is to employ a more robust synchronization model, which
! would give a <code>RowSet</code> object increased trust in the provider's
! ability to get any updates back to the original data source. Another possibility
! is a more formal synchronization mechanism such as SyncML
! (<a href="http://www.syncml.org/">http://www.syncml.org/</a>) <br>
! <br>
! <br>
! </body>
! </html>
--- 1,158 ----
! /*
! * Copyright (c) 2003, 2018, 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.
! */
!
! /**
! *
! * Repository for the <code>RowSet</code> reference implementations of the
! * <code>SyncProvider</code> abstract class. These implementations provide a
! * disconnected <code>RowSet</code>
! * object with the ability to synchronize the data in the underlying data
! * source with its data. These implementations are provided as
! * the default <code>SyncProvider</code> implementations and are accessible via the
! * <code>SyncProvider</code> SPI managed by the <code>SyncFactory</code>.
! *
! * <h3>1.0 <code>SyncProvider</code> Reference Implementations</h3>
! * The main job of a <code>SyncProvider</code> implementation is to manage
! * the reader and writer mechanisms.
! * The <code>SyncProvider</code> SPI, as specified in the <code>javax.sql.rowset.spi</code>
! * package, provides a pluggable mechanism by which <code>javax.sql.RowSetReader</code>
! * and <code>javax.sql.RowSetWriter</code> implementations can be supplied to a disconnected
! * <code>RowSet</code> object.
! * <P>
! * A reader, a <code>javax.sql.RowSetReader</code>
! * object, does the work necessary to populate a <code>RowSet</code> object with data.
! * A writer, a <code>javax.sql.RowSetWriter</code> object, does the work necessary for
! * synchronizing a <code>RowSet</code> object's data with the data in the originating
! * source of data. Put another way, a writer writes a <code>RowSet</code>
! * object's data back to the data source.
! * <P>
! * Generally speaking, the course of events is this. The reader makes a connection to
! * the data source and reads the data from a <code>ResultSet</code> object into its
! * <code>RowSet</code> object. Then it closes the connection. While
! * the <code>RowSet</code> object is disconnected, an application makes some modifications
! * to the data and calls the method <code>acceptChanges</code>. At this point, the
! * writer is called to write the changes back to the database table or view
! * from which the original data came. This is called <i>synchronization</i>.
! * <P>
! * If the data in the originating data source has not changed, there is no problem
! * with just writing the <code>RowSet</code> object's new data to the data source.
! * If it has changed, however, there is a conflict that needs to be resolved. One
! * way to solve the problem is not to let the data in the data source be changed in
! * the first place, which can be done by setting locks on a row, a table, or the
! * whole data source. Setting locks is a way to avoid conflicts, but it can be
! * very expensive. Another approach, which is at the other end of the spectrum,
! * is simply to assume that no conflicts will occur and thus do nothing to avoid
! * conflicts.
! * Different <code>SyncProvider</code> implementations may handle synchronization in
! * any of these ways, varying from doing no checking for
! * conflicts, to doing various levels of checking, to guaranteeing that there are no
! * conflicts.
! * <P>
! * The <code>SyncProvider</code> class offers methods to help a <code>RowSet</code>
! * object discover and manage how a provider handles synchronization.
! * The method <code>getProviderGrade</code> returns the
! * grade of synchronization a provider offers. An application can
! * direct the provider to use a particular level of locking by calling
! * the method <code>setDataSourceLock</code> and specifying the level of locking desired.
! * If a <code>RowSet</code> object's data came from an SQL <code>VIEW</code>, an
! * application may call the method <code>supportsUpdatableView</code> to
! * find out whether the <code>VIEW</code> can be updated.
! * <P>
! * Synchronization is done completely behind the scenes, so it is third party vendors of
! * synchronization provider implementations who have to take care of this complex task.
! * Application programmers can decide which provider to use and the level of locking to
! * be done, but they are free from having to worry about the implementation details.
! * <P>
! * The JDBC <code>RowSet</code> Implementations reference implementation provides two
! * implementations of the <code>SyncProvider</code> class:
! *
! * <UL>
! * <LI>
! * <b><code>RIOptimisticProvider</code></b> - provides the <code>javax.sql.RowSetReader</code>
! * and <code>javax.sql.RowSetWriter</code> interface implementations and provides
! * an optimistic concurrency model for synchronization. This model assumes that there
! * will be few conflicts and therefore uses a relatively low grade of synchronization.
! * If no other provider is available, this is the default provider that the
! * <code>SyncFactory</code> will supply to a <code>RowSet</code> object.
! * <br>
! * <LI>
! * <b><code>RIXMLProvider</code></b> - provides the <code>XmlReader</code> (an extension
! * of the <code>javax.sql.RowSetReader</code> interface) and the <code>XmlWriter</code>
! * (an extension of the <code>javax.sql.RowSetWriter</code> interface) to enable
! * <code>WebRowSet</code> objects to write their state to a
! * well formed XML document according to the <code>WebRowSet</code> XML schema
! * definition.<br>
! * </UL>
! *
! * <h3>2.0 Basics in RowSet Population & Synchronization</h3>
! * A rowset's first task is to populate itself with rows of column values.
! * Generally, these rows will come from a relational database, so a rowset
! * has properties that supply what is necessary for making a connection to
! * a database and executing a query. A rowset that does not need to establish
! * a connection and execute a command, such as one that gets its data from
! * a tabular file instead of a relational database, does not need to have these
! * properties set. The vast majority of RowSets, however, do need to set these
! * properties. The general rule is that a RowSet is required to set only the
! * properties that it uses.<br>
! * <br>
! * The <code>command</code> property contains the query that determines what
! * data a <code>RowSet</code> will contain. Rowsets have methods for setting a query's
! * parameter(s), which means that a query can be executed multiple times with
! * different parameters to produce different result sets. Or the query can be
! * changed to something completely new to get a new result set.
! * <p>Once a rowset contains the rows from a <code>ResultSet</code> object or some
! * other data source, its column values can be updated, and its rows can be
! * inserted or deleted. Any method that causes a change in the rowset's values
! * or cursor position also notifies any object that has been registered as
! * a listener with the rowset. So, for example, a table that displays the rowset's
! * data in an applet can be notified of changes and make updates as they
! * occur.<br>
! * <br>
! * The changes made to a rowset can be propagated back to the original data
! * source to keep the rowset and its data source synchronized. Although this
! * involves many operations behind the scenes, it is completely transparent
! * to the application programmer and remains the concern of the RowSet provider
! * developer. All an application has to do is invoke the method <code>acceptChanges</code>,
! * and the data source backing the rowset will be updated to match the current
! * values in the rowset. </p>
! *
! * <p>A disconnected rowset, such as a <code>CachedRowSet</code> or <code>WebRowSet</code>
! * object, establishes a connection to populate itself with data from a database
! * and then closes the connection. The <code>RowSet</code> object will remain
! * disconnected until it wants to propagate changes back to its database table,
! * which is optional. To write its changes back to the database (synchronize with
! * the database), the rowset establishes a connection, write the changes, and then
! * once again disconnects itself.<br>
! * </p>
! *
! * <h3> 3.0 Other Possible Implementations</h3>
! * There are many other possible implementations of the <code>SyncProvider</code> abstract
! * class. One possibility is to employ a more robust synchronization model, which
! * would give a <code>RowSet</code> object increased trust in the provider's
! * ability to get any updates back to the original data source. Another possibility
! * is a more formal synchronization mechanism such as SyncML
! * (<a href="http://www.syncml.org/">http://www.syncml.org/</a>) <br>
! */
! package com.sun.rowset.providers;
< prev index next >