> On Aug. 10, 2018, 11:58 a.m., Zsombor Gegesy wrote: > > security-admin/src/main/java/org/apache/ranger/common/db/RangerTransactionSynchronizationAdapter.java > > Lines 122 (patched) > > <https://reviews.apache.org/r/68286/diff/1/?file=2070899#file2070899line125> > > > > Why this complicated is machinery with the thread locals and lists and > > registration is needed? > > > > You can easily have the same functionality - running a 'Runnable' > > object after a transaction finish, with just like this: > > > > ```java > > public void executeOnTransactionCommit(Runnable runnable) { > > TransactionSynchronizationManager.registerSynchronization(new > > TransactionSynchronizationAdapter() { > > public void afterCommit() { > > runnable.run(); > > } > > } > > } > > ```
The main purpose of the 'machinery' is to group several tasks together and accomplish them as one atomic unit after transaction is committed. The tasks themselves have only one thing in common; that they need to be all done or all rolled back. Such atomicity cannot be achieved with the shown code fragment. - Abhay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/68286/#review207072 ----------------------------------------------------------- On Aug. 10, 2018, 12:58 a.m., Abhay Kulkarni wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/68286/ > ----------------------------------------------------------- > > (Updated Aug. 10, 2018, 12:58 a.m.) > > > Review request for ranger, Madhan Neethiraj, Ramesh Mani, and Velmurugan > Periasamy. > > > Bugs: RANGER-2186 > https://issues.apache.org/jira/browse/RANGER-2186 > > > Repository: ranger > > > Description > ------- > > Policy updates to different policies within a service, when successful, > update the service's policy version. If the update transactions are > concurrent, and executed on different ranger-admin servers (in HA > configuration), then it is possible that policy-version of the transaction > that commits later overwrites policy-version of earlier transaction, > effectively losing track of the first change. > > If policy-version is updated after update to policy is committed, then the > window of such loss is greatly reduced. > > Similar considerations apply for tag updates. > > > Diffs > ----- > > > agents-common/src/main/java/org/apache/ranger/plugin/store/AbstractServiceStore.java > 69ded6dc8 > security-admin/src/main/java/org/apache/ranger/biz/ServiceDBStore.java > 0773616f9 > > security-admin/src/main/java/org/apache/ranger/common/db/RangerTransactionSynchronizationAdapter.java > 2a62fb408 > > security-admin/src/main/java/org/apache/ranger/db/XXServiceVersionInfoDao.java > e1003297a > security-admin/src/test/java/org/apache/ranger/biz/TestServiceDBStore.java > cb496ea8b > > > Diff: https://reviews.apache.org/r/68286/diff/1/ > > > Testing > ------- > > Passed all unit tests > > > Thanks, > > Abhay Kulkarni > >
