[
https://issues.apache.org/jira/browse/SENTRY-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011813#comment-16011813
]
Alexander Kolbasov commented on SENTRY-1746:
--------------------------------------------
There is a serious problem with Oracle serializable transactions.
For example,
{code}
CREATE TABLE SENTRY_ROLE (
ROLE_ID NUMBER,
CREATE_TIME NUMBER,
ROLE_NAME VARCHAR(20)
);
ALTER TABLE "SENTRY_ROLE"
ADD CONSTRAINT "SENTRY_ROLE_PK" PRIMARY KEY ("ROLE_ID");
COMMIT;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
INSERT INTO SENTRY_ROLE (ROLE_ID,CREATE_TIME,ROLE_NAME) VALUES (100,
1233434343, 'foo_test');
COMMIT;
{code}
causes an issue with Oracle unable to serialize the transaction, but a second
attempt succeeds. This is caused by the background index updates.
So it seems like we have two solutions:
1) Use read-committed for Oracle
2) Retry transactions multiple times until it succeeds
> 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
>
> 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)
