[
https://issues.apache.org/jira/browse/HIVE-19086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438155#comment-16438155
]
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
(v7.6.3#76005)
