db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2410) Convert grantRevoke.java to JUnit
Date Sat, 10 Mar 2007 06:42:09 GMT

    [ 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.


Mime
View raw message