Alexander Kolbasov created SENTRY-1746:
------------------------------------------
Summary: 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
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.3.15#6346)
