[HIVE-18940] Hive notifications serialize all write DDL operations

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.0.0
• Component/s: Metastore
• Assignee: Unassigned Assign to me
• Reporter: Alex Kolbasov
• Created: 13/Mar/18 02:51
• Updated: 30/Mar/18 17:36

Description

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.

Issue Links

• relates to: SENTRY-1855 Improve scalability of permission delta updates
• relates to: HIVE-16886 HMS log notifications may have duplicated event IDs if multiple HMS are running concurrently

Sub-Tasks

• Write notifications in bulk only when commitTransaction actually commits: Open