[
https://issues.apache.org/jira/browse/HIVE-13966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329382#comment-15329382
]
Reuben Kuhnert commented on HIVE-13966:
---------------------------------------
Looking at this pattern in a number of metastore functions:
{code}
if (!success) {
ms.rollbackTransaction();
if (madeDir) {
wh.deleteDir(tblPath, true);
}
}
for (MetaStoreEventListener listener : listeners) {
CreateTableEvent createTableEvent =
new CreateTableEvent(tbl, success, this);
createTableEvent.setEnvironmentContext(envContext);
listener.onCreateTable(createTableEvent);
}
{code}
I'm noticing that {{DBNotificationListener}} is a subclass of
{{MetastoreEventListener}}. When you say we should not require bringing all
post event listeners into the transaction (but we do want to bring in
{{DbNotificationListener}}), would that mean having a separate hierarchy for
those listeners that *should* be part of the transaction? Is that what is meant
by 'synchronous' (part of the transaction) or do we mean 'synchronous' as in
not queued for processing later, per:
{code}
* Design overview: This listener takes any event, builds a
NotificationEventResponse,
* and puts it on a queue. There is a dedicated thread that reads entries from
the queue and
* places them in the database. The reason for doing it in a separate thread
is that we want to
* avoid slowing down other metadata operations with the work of putting the
notification into
* the database. Also, occasionally the thread needs to clean the database of
old records. We
* definitely don't want to do that as part of another metadata operation.
*/
public class DbNotificationListener extends MetaStoreEventListener {
{code}
> DbNotificationListener: can loose DDL operation notifications
> -------------------------------------------------------------
>
> Key: HIVE-13966
> URL: https://issues.apache.org/jira/browse/HIVE-13966
> Project: Hive
> Issue Type: Bug
> Components: HCatalog
> Reporter: Nachiket Vaidya
> Priority: Critical
>
> The code for each API in HiveMetaStore.java is like this:
> 1. openTransaction()
> 2. -- operation--
> 3. commit() or rollback() based on result of the operation.
> 4. add entry to notification log (unconditionally)
> If the operation is failed (in step 2), we still add entry to notification
> log. Found this issue in testing.
> It is still ok as this is the case of false positive.
> If the operation is successful and adding to notification log failed, the
> user will get an MetaException. It will not rollback the operation, as it is
> already committed. We need to handle this case so that we will not have false
> negatives.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
