[
https://issues.apache.org/jira/browse/DERBY-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479808
]
Andrew McIntyre commented on DERBY-2410:
----------------------------------------
Did a quick analysis of the lock timeout problem I was seeing with the grant
rollback test (GrantRevokeTest.testGrantRollbackAndCommit()):
I set derby.locks.waitTimeout=-1 and ran the test in client/server mode so that
I could connect and dump the lock table. The lock table shows me this for
SYSTABLEPERMS:
697 |ROW |X |SYSTABLEPERMS |(1,12) |GRANT|S |4 |NULL
700 |ROW |S |SYSTABLEPERMS |(1,12) |WAIT |S |0 |NULL
It appears that the original transaction (697), which is the connection by the
database owner which issued the grant statement, has acquired an exclusive lock
on row 12 to update SYSTABLEPERMS for the added permission. From reading the
code, I believe this is expected, as the grant statement is always executed
with isolation level REPEATABLE_READ. (See
DataDictionaryImpl.addRemovePermissionsDescriptor():10857 ). When
assertSelectPrivilege() in the test code tries to do a select on the table in
question, the code that checks permissions for the table for the select
statement blocks waiting to read the row in SYSTABLEPERMS for which the
original transaction has acquired the exclusive lock to update the permissions,
which we see in the lock table dump as the WAIT for the same row (1,12).
>From reading the code, this would appear to be expected behavior, yet the old
>grantRevoke.java test doesn't seem to hit this problem, and from reading the
>old test code, it appears to be doing almost exactly what my test code is
>doing. So, I'm a bit stumped at the moment as to what is going on that is
>causing my test to block, while the old test continues on with its processing.
I'm sure I've missed something subtle in the locking behavior, here. Or, I
suppose, I've misread the old test and somewhere along the way the grant
statement was being committed before the select checks were occurring, in which
case I think the old test wasn't actually testing what was expected to be
tested. :-)
So, if anyone has any insight as to why I'm hitting these lock timeouts, I
would greatly appreciate it.
> Convert grantRevoke.java to JUnit
> ---------------------------------
>
> Key: DERBY-2410
> URL: https://issues.apache.org/jira/browse/DERBY-2410
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: Andrew McIntyre
> Assigned To: Andrew McIntyre
> Fix For: 10.3.0.0
>
> Attachments: derby-2410-pre.diff, derby-2410-pre2.diff,
> derby-2410-pre3.diff, derby-2410-pre4.diff
>
>
> Convert grantRevoke.java to JUnit. Also add test cases from grantRevokeDDL
> and grantRevokeDDL2 SQL tests to the new GrantRevokeTest
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
