[
https://issues.apache.org/jira/browse/DERBY-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522081
]
Kristian Waagan commented on DERBY-2999:
----------------------------------------
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).
regards,
> convert lang/lockTable.sql to Junit
> -----------------------------------
>
> Key: DERBY-2999
> URL: https://issues.apache.org/jira/browse/DERBY-2999
> Project: Derby
> Issue Type: Test
> Components: Test
> Affects Versions: 10.3.1.4
> Reporter: Ravinder Reddy
> Assignee: Ravinder Reddy
> Attachments: DERBY-2999.diff-v1, DERBY-2999.diff-v2, STATUS-2999-v1,
> STATUS-v2
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
