Oops: protected void configure(Configuration cfg) { super.configure( cfg ); cfg.setProperty( Environment.BATCH_VERSIONED_DATA, "false" ); } The reasoning being that certain drivers (oracle and db2 that I know of) report an "unknown" status for these update and deletes when they are batched (no idea why...). "unknown" is not considered a failure... -----Original Message----- From: Steve Ebersole Sent: Thursday, August 31, 2006 8:43 AM To: 'Josh Moore' Cc: hibernate-dev(a)lists.jboss.org Subject: RE: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets? OptimisticLockTest was failing on certain databases because the test was poorly written; it was relying on my local setting of not using statement batching for versioned data. I have updated the test to explicitly disable batching of versioned data. Try adding the following to your local copy and see if that fixes the error you see. If not open a JIRA case with the failure, as that would be a bug. -----Original Message----- From: Josh Moore [mailto:josh.moore@gmx.de] Sent: Thursday, August 31, 2006 8:10 AM To: Steve Ebersole Cc: Max Andersen; hibernate-dev(a)lists.jboss.org; koda2(a)bbs.darktech.org Subject: Re: [hibernate-dev] Possible to confirm that versioning is broken forPersistentSets? Ok. The isDirty()/write()/add()/clearDirty() idiom explains why the patch was producing NPEs in other tests. Otherwise, the only other failures that seemed they could be related were from the optlock tests. Two were failing earlier (see http://opensource.atlassian.com/projects/hibernate/secure/attachment/125 60/TEST-org.hibernate.test.optlock.OptimisticLockTest.txt) but all are failing with the patch, e.g.: Testcase: testOptimisticLockAllDelete took 0.134 sec Caused an ERROR Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1 ~Josh. Steve Ebersole wrote: