Even if HMSFollower is running in both the nodes, we can have simple logic in HMSFollower to avoid processing duplicate notifications. Before processing the notification, if a check is added to see if the new notification id is greater than the one stored in database. If not, we ignore the notification.
-Kalyan On Mon, May 8, 2017 at 7:03 PM, Alexander Kolbasov <[email protected]> wrote: > The major problem with read-modify-write approach is that it is difficult > to handle the case with two writers trying to update the value at the same > time. If you handle this by adding new rows and having the ID as the > primary key, one writer will succeed and another will fail because the key > already exists. How would you achieve this in your approach? > > - Alex > > > On Apr 27, 2017, at 9:14 PM, Kalyan Kumar Kalvagadda < > [email protected]> wrote: > > > > Hello all, > > > > As part of SENTRY-1726, I'm adding new table to store notification-id. > HMS > > follower just needs the the latest notification-id that sentry has > > processed. > > All HMS follower needs is the latest notification. As we need not store > > older notification-id's, I defined the table to hold only one record so > > that we can avoid inserting more records in the table and the application > > should just update the existing record. > > > > > > CREATE TABLE `SENTRY_LAST_NOTIFICATION_ID` > > ( > > `NOTIFICATION_ID` BIGINT NOT NULL, > > `RESTRICTION` VARCHAR(15) NOT NULL DEFAULT 'singleton', > > CONSTRAINT `SENTRY_NOTIFICATION_PK` PRIMARY KEY (`RESTRICTION`) > > )ENGINE=INNODB; > > > > > > Application just needs to insert/update the NOTIFICATION_ID. Once we > > insert for the fist time, it is update only. > > > > On the other hand, If we have NOTIFICATION_ID as primary key and keep > > on inserting NOTIFICATION_ID's into > > > > the table. we have to use MAX(NOTIFICATION_ID) every time we need the > > notification id. Additionally, we need to build logic to cleanup older > > entries. > > > > > > You can refer to review board for complete change set. > > > > https://reviews.apache.org/r/58808/ > > > > > > -Kalyan > >
