RANGER-5148: Fix redundant role cache modify triggered by role versio…

[Gooch0922]

…n changes in concurrent scenarios.

What changes were proposed in this pull request?

Solve the problem of concurrent cache updates by clients caused by frequent modifications of role IDs.

How was this patch tested?

Tested locally.

[mneethiraj]

ret should be updated in else clause, right?

if (roleCacheWrapper.getRolesVersion() < rangerRoleVersionInDB) {
  ret = roleCacheWrapper.getLatestRangerRoles(serviceName, roleDBStore, lastKnownRoleVersion, rangerRoleVersionInDB);
} else {
  ret = roleCacheWrapper.getRoles();
}

[Gooch0922]

The variable "ret" has already been initialized and the cache has been retrieved once at line 76. There is no need to retrieve the cache repeatedly, right?

[mneethiraj]

ret initialized in line 76 is an older version, hence the if block at line 78 is entered. Consider 2 threads:

1. thread-1: ret is initialized to version=100; acquired lock at line 81
2. thread-2: ret is initialized to version=100; waiting for the lock at line 81
3. thread-1: refreshes roleCacheWrapper and ret to the latest version, say 101, at line 85; releases the lock
4. thread-2: acquires the lock, finds that roleCacheWrapper has the lastest version; skips line 85; leaves ret at version 100

The call from thread-2 will return version 100; the expected version is 101. Makes sense?