Program: 72012
Project: 72012
Buggy source:
/** 
 * Propagates all row update, insert and delete changes to the data source backing this <code>CachedRowSet</code> object using the specified <code>Connection</code> object to establish a connection to the data source. <P> The other version of the <code>acceptChanges</code> method is not passed a connection because it uses the <code>Connection</code> object already defined within the <code>RowSet</code> object, which is the connection used for populating it initially. <P> This form of the method <code>acceptChanges</code> 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 <code>Connection</code> properties must be used by the <code>SyncProvider</code> to reset the <code>RowSetWriter</code> configuration to ensure that the contents of the <code>CachedRowSet</code> object are synchronized correctly. <P> When the method <code>acceptChanges</code> 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. <P> Depending on the synchronization level of the <code>SyncProvider</code> 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 <code>RIOptimisticProvider</code> implementation, for example, throws a <code>SyncProviderException</code> and does not write anything to the data source. <P> An application may choose to catch the <code>SyncProviderException</code> object and retrieve the <code>SyncResolver</code> object it contains. The <code>SyncResolver</code> 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 <code>acceptChanges</code> 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 <code>acceptChanges</code> does nothing. <P> 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 <code>acceptChanges</code> is called.  This method may be called immediately after the methods <code>updateRow</code>, <code>insertRow</code>, or <code>deleteRow</code> 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. <P> Note: The <code>acceptChanges()</code> method will determine if the <code>COMMIT_ON_ACCEPT_CHANGES</code> 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 <b>must</b> explicity call the <code>commit</code> or <code>rollback</code> methods as appropriate.
 * @param con a standard JDBC <code>Connection</code> object
 * @throws SQLException if the cursor is on the insert row
 * @throws SyncProviderException if the underlyingsynchronization provider's writer fails to write the updates back to the data source
 * @see #acceptChanges()
 * @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
 */
public void acceptChanges(Connection con) throws SyncProviderException ;

Fixed version (ground truth):
/** 
 * Propagates all row update, insert and delete changes to the data source backing this <code>CachedRowSet</code> object using the specified <code>Connection</code> object to establish a connection to the data source. <P> The other version of the <code>acceptChanges</code> method is not passed a connection because it uses the <code>Connection</code> object already defined within the <code>RowSet</code> object, which is the connection used for populating it initially. <P> This form of the method <code>acceptChanges</code> 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 <code>Connection</code> properties must be used by the <code>SyncProvider</code> to reset the <code>RowSetWriter</code> configuration to ensure that the contents of the <code>CachedRowSet</code> object are synchronized correctly. <P> When the method <code>acceptChanges</code> 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. <P> Depending on the synchronization level of the <code>SyncProvider</code> 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 <code>RIOptimisticProvider</code> implementation, for example, throws a <code>SyncProviderException</code> and does not write anything to the data source. <P> An application may choose to catch the <code>SyncProviderException</code> object and retrieve the <code>SyncResolver</code> object it contains. The <code>SyncResolver</code> 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 <code>acceptChanges</code> 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 <code>acceptChanges</code> does nothing. <P> 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 <code>acceptChanges</code> is called.  This method may be called immediately after the methods <code>updateRow</code>, <code>insertRow</code>, or <code>deleteRow</code> 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. <P> Note: The <code>acceptChanges()</code> method will determine if the <code>COMMIT_ON_ACCEPT_CHANGES</code> 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 <b>must</b> explicity call the <code>commit</code> or <code>rollback</code> methods as appropriate.
 * @param con a standard JDBC <code>Connection</code> object
 * @throws SyncProviderException if the underlyingsynchronization provider's writer fails to write the updates back to the data source
 * @see #acceptChanges()
 * @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
 */
public void acceptChanges(Connection con) throws SyncProviderException ;