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.
[TRAFODION-2296] Consistent error reporting in abort, commit transaction. Changes to wait for all RS to respond when there is an exception in abort and commit transaction requests. When there is an error returned from commit or rollback transaction, the details of the error can be obtained in the following log files
a) $MY_SQROOT/logs/tm_.log in the node that issued this request contains the error message as seen by the TM process in the JNI side. This event may not have transaction id. b) $MY_SQROOT/logs/trafodion.dtm.log contains more info about this error with the transaction id. These events are logged from java side of TM. c) In the region server logs of all the regions that participated in the transaction.
These exceptions are visible as error code on the client side. To get the details about the exception, the above logs need to be browsed.
Fixes to avoid tm core upon double delete of incoming messages to it