Vihang Karajgaonkar commented on HIVE-19086:

The above mentioned approach is very hard to implement because the EVENT_ID is 
passed to the non-transactional listener in an in-memory structure derived from 
the actual {{ListenerEvent}} sub-classes. If we delay the EVENT_ID generation 
to the actual commit time, then we cannot pass this EVENT_ID to  using the 
existing mechanism.

[~akolb] [~thejas] Do you know what is the motivation of using this way to pass 
the EVENT_ID to non-transactional listeners? Why is it needed in the first 
place. I seems to me that the getCurrentNotificationID and 
getNextNotificationEvent APIs are sufficient to find out new events in the 
system. Why do we need to pass the EVENT_IDs to non-transactional listeners 
this way?

> Write notifications in bulk only when commitTransaction actually commits
> ------------------------------------------------------------------------
>                 Key: HIVE-19086
>                 URL: https://issues.apache.org/jira/browse/HIVE-19086
>             Project: Hive
>          Issue Type: Sub-task
>          Components: Metastore
>    Affects Versions: 3.0.0, 2.4.0
>            Reporter: Alexander Kolbasov
>            Assignee: Vihang Karajgaonkar
>            Priority: Major
> This is an optimization that is targeting reducing the amount of time the 
> global DB lock is held for notifications.
> The idea is to collect all notifications and only push them when 
> commitTransaction() actually commits.

This message was sent by Atlassian JIRA

Reply via email to