When modifying a disconnected dataset (CachedRowSet) and synching it, the SQL UPDATE queries generated cause database exceptions to be thrown. In this specific case it raises SQLIntegrityConstraintViolationException for duplicate keys, because the primary key is incorrectly being updated by the dataset/rowset implementation.

I have written a small repro for the bug I see. Briefly, this is what it does:
a) Create a table with two columns: rkey, value.
   rkey is primary key and an identity column.
b) Obtain a disconnected DataSet.
c) Modify DataSet by setting all value fields to 0.
   NOTE: The rkey field is not modified by the repro code.
d) Sync the DataSet.

In step a), 9 rows are inserted.
In step d), the first UPDATE query is correct, where only the field value is updated. For the next UPDATE queries, the UPDATE is changed to also update the rkey field. Further, the value used for rkey in the SET part is not equal to the value used in the WHERE part of the query. Below is a simplified view of the Derby database log for all queries issued but the repro.

DROP TABLE rkeyvaluetable
CREATE TABLE rkeyvaluetable (rkey int generated by default as identity,value int,PRIMARY KEY (rkey))
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -1)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -2)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -3)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -4)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -5)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -6)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -7)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -8)
INSERT INTO rkeyvaluetable VALUES (DEFAULT, -9)
SELECT * FROM rkeyvaluetable
SELECT * FROM rkeyvaluetable
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 1
UPDATE APP.rkeyvaluetable SET VALUE = 0 WHERE RKEY = 1
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 2
UPDATE APP.rkeyvaluetable SET RKEY = 3 , VALUE = 0 WHERE RKEY = 2
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 3
UPDATE APP.rkeyvaluetable SET RKEY = 4 , VALUE = 0 WHERE RKEY = 3
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 4
UPDATE APP.rkeyvaluetable SET RKEY = 5 , VALUE = 0 WHERE RKEY = 4
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 5
UPDATE APP.rkeyvaluetable SET RKEY = 6 , VALUE = 0 WHERE RKEY = 5
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 6
UPDATE APP.rkeyvaluetable SET RKEY = 7 , VALUE = 0 WHERE RKEY = 6
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 7
UPDATE APP.rkeyvaluetable SET RKEY = 8 , VALUE = 0 WHERE RKEY = 7
SELECT RKEY, VALUE FROM APP.rkeyvaluetable WHERE RKEY = 8
UPDATE APP.rkeyvaluetable SET RKEY = 9 , VALUE = 0 WHERE RKEY = 8

Tests done with Derby 10.2 (snapshot 10.2.0.2, r410284) and Mustang beta build 85. To run the repro, you only need 'derby.jar' in your classpath. IMPORTANT! This snapshot will not work with Mustang build 86 and later. If you download a newer snapshot, it will not work with Mustang build 85. This is because of some renamed classes and methods.

I'm attaching the repro Java sources (compile and run with Mustang), the console output and the complete Derby log file.