[jira] [Assigned] (SENTRY-1746) Investigate problems with Oracle and serializable transactions

["Alexander Kolbasov (JIRA)" <ji...@apache.org>]

     [ 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)