Hi, Sasha It is still problematic due to the max(change ID) scanning.
One possible way to address it is that, in HMSFollower#run(), it ask sentryStore to cache max change IDs of these two tables with in sentryStore itself. So that each time, when HMSFollower wake up, it refresh sentryStore's cached change ID value. And since DB write is fenced, so the cached change IDs should be valid during the execution ? Do you know whether SentryPolicyStoreProcessor is also fenced by leaderMonitor? SentryPolicyStoreProcessor also has a write path to the DB via SentryStore. On Wed, Jun 7, 2017 at 10:05 PM, Alexander Kolbasov <[email protected]> wrote: > Lei, > > Thank you for fixing SENTRY-1795. I remember we had some issues earlier with > this approach - see some discussion in SENTRY-1706 where you encountered a > deadlock issue. > > Do you think that this is still a problem or not? > > - Sasha -- Lei (Eddy) Xu Software Engineer, Cloudera
