[
https://issues.apache.org/jira/browse/SENTRY-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049786#comment-16049786
]
Hadoop QA commented on SENTRY-1746:
-----------------------------------
Here are the results of testing the latest attachment
https://issues.apache.org/jira/secure/attachment/12873022/SENTRY-1746.01-sentry-ha-redesign.patch
against sentry-ha-redesign.
{color:green}Overall:{color} +1 all checks pass
{color:green}SUCCESS:{color} all tests passed
Console output:
https://builds.apache.org/job/PreCommit-SENTRY-Build/2885/console
This message is automatically generated.
> Investigate problems with Oracle and serializable transactions
> --------------------------------------------------------------
>
> Key: SENTRY-1746
> URL: https://issues.apache.org/jira/browse/SENTRY-1746
> Project: Sentry
> Issue Type: Bug
> Components: Sentry
> Affects Versions: 1.8.0, sentry-ha-redesign
> Reporter: Alexander Kolbasov
> Assignee: Alexander Kolbasov
> Labels: Oracle, serializable, transactions
> Attachments: SENTRY-1746.01-sentry-ha-redesign.patch
>
>
> We discovered during testing with Oracle that when transaction level is set
> to Serializable, a lot of transactions start to fail complaining about
> failure to serialize.
> We need to investigate the causes for this.
> One thing that we discovered is that the simple createSentryRole() fails.
> This one is:
> {code}
> String trimmedRoleName = trimAndLower(roleName);
> if (getRole(pm, trimmedRoleName) != null) {
> throw new SentryAlreadyExistsException("Role: " +
> trimmedRoleName);
> }
> pm.makePersistent(new MSentryRole(trimmedRoleName));
> {code}
> If we try this operation, for multiple roles, an interesting thing happens.
> The first time it fails, the second two succeed, then the next one fails
> again, the two more succeed, etc.
> This failure is masked by our transaction retry mechanism, so we need to
> disable it to see the failures.
> Removal of the check for existing roles fixes this particular problem. It
> seems that Oracle isn't happy when we scan the table and modify it in the
> same transaction which we do in multiple other cases.
> Another discovered case is {{alterSentryRoleGrantPrivilegeCore}}:
> which does
> {code}
> pm.makePersistent(mRole);
> pm.makePersistent(mPrivilege);
> {code}
> It is quite possible that we do not need to make both persistent.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
