[
https://issues.apache.org/jira/browse/HIVE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16408460#comment-16408460
]
Jesus Camacho Rodriguez commented on HIVE-18948:
------------------------------------------------
AFAIK, the WriteEntity type is extracted from operation type, which in turn can
be inferred from AST directly. In some occasions, we need some additional
information, e.g., whether a table is transactional or not, to create the
correct lock. In those cases, we need to make a call to metastore to obtain the
table object, probably while we are acquiring the lock, or maybe while we are
extracting the information from the AST, I do not think we can get around that.
As for the effort, I think this can be done in a couple of weeks. However, the
change will involve quite a bit of refactoring and changes in the txn manager
APIs, e.g., DBTxnManager now relies on query plan, while it should rely on
read/write entities, etc. (or new objects if we want to remove this dependency
all together).
> Acquire locks before generating the valid transaction list
> ----------------------------------------------------------
>
> Key: HIVE-18948
> URL: https://issues.apache.org/jira/browse/HIVE-18948
> Project: Hive
> Issue Type: Improvement
> Components: Transactions
> Affects Versions: 3.0.0
> Reporter: Jesus Camacho Rodriguez
> Priority: Critical
>
> HIVE-18825 moves the valid transaction list generation logic before query
> optimization. In order to support lock-based concurrency control correctly,
> the logic to acquire the locks has to be moved before query optimization too,
> and before the valid transaction list is generated.
> This requires a bit of work/refactoring, since lock acquisition logic relies
> on read/write entities, and it is heavily dependent on the QueryPlan object
> too, e.g., it sets some properties in the file sink descriptors for the plan.
> Currently, all these data structures (except for read entities) are only
> available after query has been optimized, hence we will need to 1) generate
> some of this data structures before query optimization, e.g., write entities,
> and 2) create and propagate some of the properties so they are set during
> query optimization, e.g., those properties contained in the file sink
> descriptors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
