Help me understand why should we be concerned about locking. As far I know there are two threads that will be interested in last notification id 1. HMS Follower to construct request to pull the latest notification 2. Sentry Metrics
HMSFollower should get this information from database every time it needs and have a in-memory copy. Other components like Metrics could depend on the in-memory copy stored by HMSFollower. Even if, we want to avoid using in-memory copy and use the database always, I don't know if locking would be an issue as there will not many requests to read the notification-id other then HMSFollower thread. -Kalyan On Fri, Apr 28, 2017 at 2:00 AM, Alexander Kolbasov <[email protected]> wrote: > Hello Kalyan, > > > 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. > > I think it is better to store new notification ID as a new row .This will > avoid holding a row lock for read-edify-write operation. The dwnside that > we need to use MAX(), but given that tis is the primary key, MAX() should > be an index scan rather then a table scan. And yes, we do need to prune old > rows, we should be able to do that in the background to keep the table size > small. > > > > > > > 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 > >
