This method calls on this CachedRowSet object's writer to do the work behind the scenes. Standard CachedRowSet implementations should use the SyncFactory singleton to obtain a SyncProvider instance providing a RowSetWriter object (writer). The writer will attempt to propagate changes made in this CachedRowSet object back to the data source.

When the method acceptChanges executes successfully, in addition to writing changes to the data source, it makes the values in the current row be the values in the original row.

Depending on the synchronization level of the SyncProvider implementation being used, the writer will compare the original values with those in the data source to check for conflicts. When there is a conflict, the RIOptimisticProvider implementation, for example, throws a SyncProviderException and does not write anything to the data source.

An application may choose to catch the SyncProviderException object and retrieve the SyncResolver object it contains. The SyncResolver object lists the conflicts row by row and sets a lock on the data source to avoid further conflicts while the current conflicts are being resolved. Further, for each conflict, it provides methods for examining the conflict and setting the value that should be persisted in the data source. After all conflicts have been resolved, an application must call the acceptChanges method again to write resolved values to the data source. If all of the values in the data source are already the values to be persisted, the method acceptChanges does nothing.

Some provider implementations may use locks to ensure that there are no conflicts. In such cases, it is guaranteed that the writer will succeed in writing changes to the data source when the method acceptChanges is called. This method may be called immediately after the methods updateRow, insertRow, or deleteRow have been called, but it is more efficient to call it only once after all changes have been made so that only one connection needs to be established.

Note: The acceptChanges() method will determine if the COMMIT_ON_ACCEPT_CHANGES is set to true or not. If it is set to true, all updates in the synchronization are committed to the data source. Otherwise, the application must explicity call the commit() or rollback() methods as appropriate.

The other version of the acceptChanges method is not passed a connection because it uses the Connection object already defined within the RowSet object, which is the connection used for populating it initially.

This form of the method acceptChanges is similar to the form that takes no arguments; however, unlike the other form, this form can be used only when the underlying data source is a JDBC data source. The updated Connection properties must be used by the SyncProvider to reset the RowSetWriter configuration to ensure that the contents of the CachedRowSet object are synchronized correctly.

When the method acceptChanges executes successfully, in addition to writing changes to the data source, it makes the values in the current row be the values in the original row.

Depending on the synchronization level of the SyncProvider implementation being used, the writer will compare the original values with those in the data source to check for conflicts. When there is a conflict, the RIOptimisticProvider implementation, for example, throws a SyncProviderException and does not write anything to the data source.

An application may choose to catch the SyncProviderException object and retrieve the SyncResolver object it contains. The SyncResolver object lists the conflicts row by row and sets a lock on the data source to avoid further conflicts while the current conflicts are being resolved. Further, for each conflict, it provides methods for examining the conflict and setting the value that should be persisted in the data source. After all conflicts have been resolved, an application must call the acceptChanges method again to write resolved values to the data source. If all of the values in the data source are already the values to be persisted, the method acceptChanges does nothing.

Some provider implementations may use locks to ensure that there are no conflicts. In such cases, it is guaranteed that the writer will succeed in writing changes to the data source when the method acceptChanges is called. This method may be called immediately after the methods updateRow, insertRow, or deleteRow have been called, but it is more efficient to call it only once after all changes have been made so that only one connection needs to be established.

Note: The acceptChanges() method will determine if the COMMIT_ON_ACCEPT_CHANGES is set to true or not. If it is set to true, all updates in the synchronization are committed to the data source. Otherwise, the application must explicity call the commit or rollback methods as appropriate.

Makes all changes that are performed by the acceptChanges() method since the previous commit/rollback permanent. This method should be used only when auto-commit mode has been disabled.

Applications can form a WebRowSet object from the CachedRowSet object returned by this method in order to export the RowSet schema definition to XML for future use.

In addition, any RowSet object created by this method will have the same properties as this CachedRowSet object. For example, if this CachedRowSet object is read-only, all of its duplicates will also be read-only. If it is changed to be updatable, the duplicates also become updatable.

NOTE: If multiple threads access RowSet objects created from the createShared() method, the following behavior is specified to preserve shared data integrity: reads and writes of all shared RowSet objects should be made serially between each object and the single underlying tabular structure.

The reader for this CachedRowSet object will use conn to establish a connection to the data source so that it can execute the rowset's command and read data from the the resulting ResultSet object into this CachedRowSet object. This method also closes conn after it has populated this CachedRowSet object.

If this method is called when an implementation has already been populated, the contents and the metadata are (re)set. Also, if this method is called before the method acceptChanges has been called to commit outstanding updates, those updates are lost.

The cursor for the ResultSet object should be positioned before the first row. In addition, the returned ResultSet object should have the following properties:

• ResultSet.TYPE_SCROLL_INSENSITIVE
• ResultSet.CONCUR_UPDATABLE

The original value for a RowSet object is the value it had before the last synchronization with the underlying data source. If there have been no synchronizations, the original value will be the value with which the RowSet object was populated. This method is called internally when an aplication calls the method acceptChanges and the SyncProvider object has been implemented to check for conflicts. If this is the case, the writer compares the original value with the value currently in the data source to check for conflicts.

The cursor for the ResultSet object should be positioned before the first row. In addition, the returned ResultSet object should have the following properties:

• ResultSet.TYPE_SCROLL_INSENSITIVE
• ResultSet.CONCUR_UPDATABLE

Standard rowset implementations may choose to restrict this behavior due to security considerations or to better fit certain deployment scenarios. This is left as implementation defined and does not represent standard behavior.

Note: Allowing deleted rows to remain visible complicates the behavior of some standard JDBC RowSet Implementations methods. However, most rowset users can simply ignore this extra detail because only very specialized applications will likely want to take advantage of this feature.

     RowSetReader rowsetReader = null;
     SyncProvider provider = 
         SyncFactory.getInstance("javax.sql.rowset.provider.RIOptimisticProvider");
         if (provider instanceof RIOptimisticProvider) {
             rowsetReader = provider.getRowSetReader();
         }
 

    
     rowsetReader.readData((RowSetInternal)this);
 

In addition, an application can use the SyncProvider object returned by this method to call methods that return information about the SyncProvider object, including information about the vendor, version, provider identification, synchronization grade, and locks it currently has set.

This method can be used as an alternative to the execute method when an application has a connection to an open ResultSet object. Using the method populate can be more efficient than using the version of the execute method that takes no parameters because it does not open a new connection and re-execute this CachedRowSet object's command. Using the populate method is more a matter of convenience when compared to using the version of execute that takes a ResultSet object.

This method can be used as an alternative to the execute method when an application has a connection to an open ResultSet object. Using the method populate can be more efficient than using the version of the execute method that takes no parameters because it does not open a new connection and re-execute this CachedRowSet object's command. Using the populate method is more a matter of convenience when compared to using the version of execute that takes a ResultSet object.

This CachedRowSet object should lock until its contents and associated updates are fully cleared, thus preventing 'dirty' reads by other components that hold a reference to this RowSet object. In addition, the contents cannot be released until all all components reading this CachedRowSet object have completed their reads. This CachedRowSet object should be returned to normal behavior after firing the rowSetChanged event.

The metadata, including JDBC properties and Synchronization SPI properties, are maintained for future use. It is important that properties such as the command property be relevant to the originating data source from which this CachedRowSet object was originally established.

This method empties a rowset, as opposed to the close method, which marks the entire rowset as recoverable to allow the garbage collector the rowset's Java VM resources.

When this method is called, a CachedRowSet implementation must ensure that all updates, inserts, and deletes to the current rowset instance are replaced by the previous values. In addition, the cursor should be reset to the first row and a rowSetChanged event should be fired to notify all registered listeners.

Undoes all changes made in the current transaction. This method should be used only when auto-commit mode has been disabled.

Undoes all changes made in the current transaction back to the last Savepoint transaction marker. This method should be used only when auto-commit mode has been disabled.

The source of the event can be retrieved with the method event.getSource.

If a CachedRowSet object becomes part of a JoinRowSet object, the keys defined by this method and the resulting constraints are maintained if the columns designated as key columns also become match columns.

This method is called internally after the any modified values in the current row have been synchronized with the data source. The current row must be tagged as no longer inserted, deleted or updated.

A call to setOriginalRow is irreversible.

Standard rowset implementations may choose to restrict this behavior due to security considerations or to better fit certain deployment scenarios. This is left as implementations defined and does not represent standard behavior.

A CachedRowSet implementation should always be instantiated with an available SyncProvider mechanism, but there are cases where resetting the SyncProvider object is desirable or necessary. For example, an application might want to use the default SyncProvider object for a time and then choose to use a provider that has more recently become available and better fits its needs.

Resetting the SyncProvider object causes the RowSet object to request a new SyncProvider implementation from the SyncFactory. This has the effect of resetting all previous connections and relationships with the originating data source and can potentially drastically change the synchronization behavior of a disconnected rowset.

The implementation of this CachedRowSet object may obtain the the name internally from the RowSetMetaDataImpl object.

The standard reference implementation for the CachedRowSet interface uses a TreeMap object for the rowset, with the values in each row being contained in Vector objects. It is expected that most implementations will do the same.

The TreeMap type of collection guarantees that the map will be in ascending key order, sorted according to the natural order for the key's class. Each key references a Vector object that corresponds to one row of a RowSet object. Therefore, the size of each Vector object must be exactly equal to the number of columns in the RowSet object. The key used by the TreeMap collection is determined by the implementation, which may choose to leverage a set key that is available within the internal RowSet tabular structure by virtue of a key already set either on the RowSet object itself or on the underlying SQL data.

The standard reference implementation uses a Vector object to contain the column values, and it is expected that most implementations will do the same. If a Vector object is used, it size must be exactly equal to the number of rows in this CachedRowSet object.

The standard reference implementation uses a Vector object to contain the column values, and it is expected that most implementations will do the same. If a Vector object is used, it size must be exactly equal to the number of rows in this CachedRowSet object.

In addition, multiple cancellations of row deletions can be made by adjusting the position of the cursor using any of the cursor position control methods such as:

• CachedRowSet.absolute
• CachedRowSet.first
• CachedRowSet.last

In addition, multiple cancellations of row insertions can be made by adjusting the position of the cursor using any of the cursor position control methods such as:

• CachedRowSet.absolute
• CachedRowSet.first
• CachedRowSet.last

undoUpdate