db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (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 Fri, 21 Jul 2006 17:59:16 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1539?page=comments#action_12422730 ] 
            
Mamta A. Satoor commented on DERBY-1539:
----------------------------------------

I want to start out by saying that this is my first time ever working with hashCode so I am
new to this part of the code and hence new to the terminology. Having said that, I debugged
through permissions caching and found that Permission Descriptor does not change its hashCode
during its lifetime in the cache. I did my debugging for a TablePermissionsDescriptor and
same logic should apply to ColPermsDescriptor and RoutinePermsDescriptor.

Following are more details from debugging
1)When a statement such as create view is compiled, a list of privileges are collected for
it. At this point, we only know of tableUUID and grantee and the required privilege type and
know nothing about the Permission Descriptor's UUID since we haven't gone to system tables
yet. 
During the statement's execution phase, one required privilege is taken at a time. For each
one of them, we first create a Permission Descriptor using the tableUUID, permission type
and grantee as PUBLIC. We find if there is such a granted permission by going to system tables
and if yes, then we get that permission's UUID and put it in the Permission Descriptor object
and save it in the hash table using the tableUUID and grantee as the hash key(so the entry
in the has table will have both UUID and tableUUID) and we move on to the next required privilege.
 
If there is no PUBLIC level privilege found, then the Permission Descriptor with tableUUID,
grantee as PUBLIC and no UUID is added to the hash table and we look for the privilege at
the user specific level in the permissions system tables. 
If we find a privilege granted at the user level, then we add a Permission Descriptor with
the UUID for that privilege(found from the system table), tableUUID and grantee as the actual
user in the hash table and we move on to the next required privilege. Ofcourse, if no privilege
found at PUBLIC or user level, there will be an exception thrown.
So, at the end of the statement execution, the hash table would have permissions descriptors
with or without UUIDs depending on whether a permission was granted at the PUBLIC or user
level. But in both cases, the hashkey used is based on tableUUID and grantee.

2)Next, when revoke privilege is called, dependency manager has access to the UUID of the
privilege. It looks in the hashtable using UUID for the haskey(we do not know the tableUUID
at this point and hence have to reply on UUID. This is the code change that I made in this
patch). Since the earlier entries in hashtable is step 1) above were based on the hashcode
of tableUUID and grantee, we will not find the entry in the hash table based on the UUID.
The cahing code makes an entry in the hashtable using the hashkey based on UUID and as part
of the remaining logic in the caching code for a new entry, we goto system tables and get
the remaining information about Permission Descriptor which includes tableUUID, grantee, permission
type etc. This happens in PermssionsCacheable.setIdentity. During this time, caching code
finds that there is already an entry in the hashtable for the tableUUID and grantee(which
were just found from the system table) and hence it uses the existing hashtable entry and
removes the entry that was made using UUID as the hashkey. So, this is what ensures that a
Permission Descriptor does not change its hashCode during its lifetime in the cache and we
continue to use tableUUID and grantee to get stuff from the cache or to add stuff into the
cache. 

The stack trace of where we abandon the hashentry made using UUID and reuse the existing hasttable
entry based on tableUUID and grantee is as follows
	PermissionsCacheable.setIdentity(Object) line: 66
	CachedItem.takeOnIdentity(CacheManager, CacheableFactory, Object, boolean, Object) line:
235
	Clock.addEntry(CachedItem, Object, boolean, Object) line: 796
	Clock.find(Object) line: 301
	DataDictionaryImpl.getPermissions(PermissionsDescriptor) line: 9796
	DataDictionaryImpl.getTablePermissions(UUID) line: 9790
	DDdependableFinder.getDependable(DataDictionary, UUID) line: 354
	DDdependableFinder.getDependable(UUID) line: 180
	BasicDependencyManager.getDependencyDescriptorList(List) line: 1190
	BasicDependencyManager.getDependents(Provider) line: 1370
	BasicDependencyManager.coreInvalidateFor(Provider, int, LanguageConnectionContext) line:
247
	BasicDependencyManager.invalidateFor(Provider, int, LanguageConnectionContext) line: 224
	TablePermsDescriptor.sendInvalidationMessages(DependencyManager, LanguageConnectionContext)
line: 194
	DataDictionaryImpl.addRemovePermissionsDescriptor(boolean, PermissionsDescriptor, String,
TransactionController) line: 10004
	TablePrivilegeInfo.executeGrantRevoke(Activation, boolean, List) line: 131
	GrantRevokeConstantAction.executeConstantAction(Activation) line: 61
	MiscResultSet.open() line: 56
	GenericPreparedStatement.execute(Activation, boolean, long) line: 357
	EmbedStatement.executeStatement(Activation, boolean, boolean) line: 1181
	EmbedStatement.execute(String, boolean, boolean, int, int[], String[]) line: 584
	EmbedStatement.execute(String) line: 516
	ij.executeImmediate(String) line: 313
	utilMain14(utilMain).doCatch(String) line: 433
	utilMain14(utilMain).go(LocalizedInput[], LocalizedOutput, Properties) line: 310
	Main14(Main).go(LocalizedInput, LocalizedOutput, Properties) line: 207
	Main.mainCore(String[], Main) line: 173
	Main14.main(String[]) line: 55
	ij.main(String[]) line: 60


Dan, I hope this answers your question.

> 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

       

Mime
View raw message