This makes sense. Since normally HMSFollower is only running on one server, there shouldn’t be any contention, so read/modify/write should be fine in this case.
> On Apr 28, 2017, at 8:30 AM, Kalyan Kumar Kalvagadda <[email protected]> > wrote: > > 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 >> >>
