[ 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: 10.2.0.0 > Reporter: Mamta A. Satoor > Assigned To: Mamta A. Satoor > Fix For: 10.2.0.0 > > 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
