Alexander Kolbasov commented on HIVE-18940:

[~thejas] Yes, you are correct, this is a nice assumption to work from, the 
only problem is that there is no way we can guarantee it *and* avoid global 
synchronization of all write HMS events. This means that we need to think about 
alternative solutions that can relax the accepted behavior of notification 
stream. We might provide both 'strict' and 'relaxed' modes, which is Ok, but 
complicates HMS even more because we may need different tables and HM methods 
to implement the two.

> Hive notifications serialize all write DDL operations
> -----------------------------------------------------
>                 Key: HIVE-18940
>                 URL: https://issues.apache.org/jira/browse/HIVE-18940
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore
>    Affects Versions: 3.0.0
>            Reporter: Alexander Kolbasov
>            Priority: Major
> The implementation of DbNotificationListener uses a single row to store 
> current notification ID and uses {{SELECT FOR UPDATE}} to lock the row. This 
> serializes all write DDL operations which isn't good.
> We should consider using database auto-increment for notification ID instead. 
> Especially on mMySQL/innoDb it is supported natively with relatively 
> light-weight locking. 
> This creates potential issue for consumers though because such IDs may have 
> holes. There are two types of holes - transient hole for a transaction which 
> have not committed yet and will be committed shortly and permanent holes for 
> transactions that fail. Consumers need to deal with it. It may be useful to 
> add DB-generated timestamp as well to assist in recovery from holes.

This message was sent by Atlassian JIRA

Reply via email to