Thanks for addressing comment 1 and 4.
Regarding comment 2, I'm wondering if you should use a decorator to set the appropriate Derby properties to make the test run faster. In the old test derby.storage.rowLocking=false was also set. Is this no longer needed?
For comment 3, I don't see any verification of the locks by querying the lock table. If that is a conscious choice, then consider my comment addressed. However, I don't really understand what is tested in "-- verify that user getting error on lock table doesn't get rolled back". The test case does not seem to verify that the other user still has its locks after the exception is thrown.
And in the method "testTXvsTXLocks", maybe trying to insert a row with connection c2 would be a nice addition to the test?
Another small thing I noticed, is that dropping the table in the test methods should not be required since you run with auto commit off and do a rollback in the tearDown-method, and also the tables are dropped in setUp.
The main reason for removing it from the test method would be to make it smaller and have it only contain code relevant to what's being tested, the secondary reason would be to do things only once (or twice).