[SENTRY-1746] Investigate problems with Oracle and serializable transactions

• Type: Bug
• Status: Patch Available
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.8.0, 2.0.0
• Component/s: Sentry
• Labels: Oracle serializable transactions
• Assignee: Unassigned
• Reporter: Alex Kolbasov
• Created: 02/May/17 04:33
• Updated: 22/Sep/17 22:15

Description

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:

            String trimmedRoleName = trimAndLower(roleName);
            if (getRole(pm, trimmedRoleName) != null) {
              throw new SentryAlreadyExistsException("Role: " + trimmedRoleName);
            }
            pm.makePersistent(new MSentryRole(trimmedRoleName));
 

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

     pm.makePersistent(mRole);
      pm.makePersistent(mPrivilege);

It is quite possible that we do not need to make both persistent.

Issue Links

• links to: Oracle challenge with serializable transactions
• links to: Oracle issues with serializable