[
https://issues.apache.org/jira/browse/TRAFODION-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622317#comment-15622317
]
ASF GitHub Bot commented on TRAFODION-2327:
-------------------------------------------
GitHub user robertamarton opened a pull request:
https://github.com/apache/incubator-trafodion/pull/803
TRAFODION-2327 Reduce I/O when loading objects into caches
For each authorization ID (user, role, or PUBLIC), a bitmap containing the
accumulated privileges (across all grantors) is stored with the object desc.
When the object desc is loaded into cache, the privilege bitmaps associated
with the current user, PUBLIC, and the current users' roles are extracted
and
unioned together to calculate the final set of privileges. This unioned
list
is used during privilege checking.
Today, an I/O is performed to retrieve the list of roles granted to the
current
user for each object loaded into NATable and NARoutine cache. Since this
list
does not change unless the current user changes (a new session with a
different
user) or a grant/revoke role for the current user is performed, these extra
I/O's are not needed.
To remove the extra I/O's for each object, the list of roles will be stored
in
the ContextCli. Therefore, this in-memory role list can be used instead of
rereading metadata.
This checkin creates two new CLI requests:
- GetRoleList - returns the list of roles associated with the user
If the list exists in ContextCli, it returns the stored values
If the list does not exist, it retrieves them from Metadata, stores
them and returns the values
- ResetRoleList - removes the list of roles from ContextCli
The first time GetRoleList is called in a session, the users' roles are
stored in ContextCli. They remain in memory until the session ends and
restarts as a different user, or another process grants or revokes a role
from the current user.
If another process revokes a role from the current user, a query
invalidation
key is created. When the revoke role query invalidation key for the current
user is detected, ResetRoleList is called. The next time GetRoleList is
called
an updated role list is retrieved from metadata and stored in ContextCli.
If another process grants a role to the current user, there could be two
outcomes. If the current user already has the privilege from another source
then nothing happens. If the current user does not have the privilege, then
one recompilation is attempted. Prior to performing the retry, code was
added to ResetRoleList. The recompilation then gets the latest role list
and
either succeeds or fails depending on the granted privileges.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/robertamarton/incubator-trafodion activeroles
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-trafodion/pull/803.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #803
----
commit 1c8f25b6e61c47383f43633a4ffa7d0bda766cd9
Author: Roberta Marton <[email protected]>
Date: 2016-10-31T14:28:54Z
TRAFODION-2327 Reduce I/O when loading objects into caches
For each authorization ID (user, role, or PUBLIC), a bitmap containing the
accumulated privileges (across all grantors) is stored with the object desc.
When the object desc is loaded into cache, the privilege bitmaps associated
with the current user, PUBLIC, and the current users' roles are extracted
and
unioned together to calculate the final set of privileges. This unioned
list
is used during privilege checking.
Today, an I/O is performed to retrieve the list of roles granted to the
current
user for each object loaded into NATable and NARoutine cache. Since this
list
does not change unless the current user changes (a new session with a
different
user) or a grant/revoke role for the current user is performed, these extra
I/O's are not needed.
To remove the extra I/O's for each object, the list of roles will be stored
in
the ContextCli. Therefore, this in-memory role list can be used instead of
rereading metadata.
This checkin creates two new CLI requests:
- GetRoleList - returns the list of roles associated with the user
If the list exists in ContextCli, it returns the stored values
If the list does not exist, it retrieves them from Metadata, stores
them and returns the values
- ResetRoleList - removes the list of roles from ContextCli
The first time GetRoleList is called in a session, the users' roles are
stored in ContextCli. They remain in memory until the session ends and
restarts as a different user, or another process grants or revokes a role
from the current user.
If another process revokes a role from the current user, a query
invalidation
key is created. When the revoke role query invalidation key for the current
user is detected, ResetRoleList is called. The next time GetRoleList is
called
an updated role list is retrieved from metadata and stored in ContextCli.
If another process grants a role to the current user, there could be two
outcomes. If the current user already has the privilege from another source
then nothing happens. If the current user does not have the privilege, then
one recompilation is attempted. Prior to performing the retry, code was
added to ResetRoleList. The recompilation then gets the latest role list
and
either succeeds or fails depending on the granted privileges.
----
> Reduce I/O when loading objects into NATable and NARoutine cache
> ----------------------------------------------------------------
>
> Key: TRAFODION-2327
> URL: https://issues.apache.org/jira/browse/TRAFODION-2327
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-cmp, sql-security
> Reporter: Roberta Marton
> Assignee: Roberta Marton
>
> This is a request to reduce the number of I/O's performed when objects are
> loaded into caches. Today, the list of roles is read from Metadata every time
> any object is placed into NATable and NARoutine cache. Since the list of
> roles associated with the current user is the same independent of the object
> being referenced, redundant I/O's are performed. The list of roles does
> change whenever a grant or revoke role is performed against the user, so the
> solution must make sure grant and revoke operations are handled correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
