> On May 8, 2017, at 5:11 PM, Kalyan Kumar Kalvagadda <[email protected]>
> wrote:
>
> 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.
Imagine two threads. Both start with the same notification ID. Both see that
the new one is greater then the on win the database. And both successfully
write the new value. What would prevent this scenario from happening?
Another scenario (much more dangerous):
Thread one reads current notification ID and it is 10
after that thread 2 processes ten notifications and now current ID is 20
Thread 1 processes single notification and writes value 11. Note that it will
not see updates from another threads because we are using repeatable-read
transaction isolation level.
- Alex
>
> -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
>>
>>
