[
https://issues.apache.org/jira/browse/HIVE-8311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153803#comment-14153803
]
Eugene Koifman commented on HIVE-8311:
--------------------------------------
previously, locks were acquired 1st, then valid transaction list computed.
Now the order is reversed. So now it's possible that txn list is computed,
then a new txn (on a resource in in this TX) runs, then locks are acquired. I
think, strictly speaking this is a race condition - for example a compactor run
may sneak in here. Does this seem like an issue?
Does hive cache query plans? If so, it will need to be invalidated when valid
txn list changes
> Driver is encoding transaction information too late
> ---------------------------------------------------
>
> Key: HIVE-8311
> URL: https://issues.apache.org/jira/browse/HIVE-8311
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 0.14.0
> Reporter: Alan Gates
> Assignee: Alan Gates
> Priority: Blocker
> Fix For: 0.14.0
>
> Attachments: HIVE-8311.patch
>
>
> Currently Driver is obtaining the transaction information and encoding it in
> the conf in runInternal. But this is too late, as the query has already been
> planned. Either we need to change the plan when this info is obtained or we
> need to obtain it at compile time. This bug was introduced by HIVE-8203.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
