[
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
