db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1539) As per the functional spec attached to DERBY-1330, a trigger should be dropped when a privilege required by the trigger is revoked.
Date Sun, 23 Jul 2006 17:03:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1539?page=comments#action_12422925 ] 
Daniel John Debrunner commented on DERBY-1539:

Mamta & I had a quick IM discussion to align our understanding of the issue:

I was confused as to why in a simple REVOKE statement the DependencyManager (DM) was trying
to fetch the PermissionsDescriptor for the item being revoked during the invalidation of said
item. Ie. The call to DM.invalidateFor() takes the PermissionsDescriptor as the provider so
why would it need to load it again?

Thanks to Mamta's patience with my questions we discovered that during the DM.invalidateFor()
call, the DM loads the set of persistent dependencies  for the Provider (in this case the
revoked permission) and then converts them to an in-memory form. In this conversion to an
in-memory form the DM needs a Provider object to link it to the Dependent and loads the Dependent's
Provider *each* time from the DataDictionary (DD) through its UUID. This is the load by UUID
from the DD that was causing Mamta's code to have problems. The issue with this code is that
the Provider object is the same for all the Dependents (since the list is derived from those
objects dependent on a singel Provider)  thus loading it multple times is inefficient,  *and*
it's the same Provider that was passed into invalidateFor() , thus no-need to load it from
the DD at all.

To verify this was indeed the case, I created a table T and created three views against the
table.  When a DROP TABLE T was executed I did see three loads of the TableDescriptor for
T and it matched the TTableDescriptor passed into DM.invalidateFor.

 Thus what is really happening is that Mamta  has un-earthed some inefficient behaviour in
the DM implementation. I'll enter a separate bug for this and I have some code to address
it, I need to run complete tests first. I'm slowed down by the fact it's so hot at home (heatwave
& no a/c) I can't leave my laptop on  too long otherwise it gets really hot.

There may still be an issue with the permissions cache, I couldn't find any thing in the GRANT/REVOKE
design spec or the code that  described its use and design.

> As per the functional spec attached to DERBY-1330, a trigger should be dropped when a
privilege required by the trigger is revoked.
> -----------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1539
>                 URL: http://issues.apache.org/jira/browse/DERBY-1539
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions:
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>             Fix For:
>         Attachments: DERBY1539V1hashCodeEqualsDiff.txt, DERBY1539V1hashCodeEqualsStat.txt
> A trigger tracks its privileges requirements using Derby's Dependency Manager. If any
one of those required privileges are revoked, the trigger should be dropped automatically.

> I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330.
Will link this Jira entry to DERBY-1330.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message