CachedRowSet object to the underlying data source. 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.
@throws SyncProviderException if the underlyingsynchronization provider's writer fails to write the updates back to the data source
@see #acceptChanges(java.sql.Connection)
@see javax.sql.RowSetWriter
@see javax.sql.rowset.spi.SyncFactory
@see javax.sql.rowset.spi.SyncProvider
@see javax.sql.rowset.spi.SyncProviderException
@see javax.sql.rowset.spi.SyncResolver
| |
| |
| |
| |