[
https://issues.apache.org/jira/browse/SENTRY-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kolbasov reassigned SENTRY-1746:
------------------------------------------
Assignee: (was: Alexander Kolbasov)
> 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, 2.0.0
> Reporter: 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)
