[
https://issues.apache.org/jira/browse/HIVE-8850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218230#comment-14218230
]
Chaoyu Tang commented on HIVE-8850:
-----------------------------------
[~sushanth] Thanks for the deep insight and analysis to the cause of the
"unbalanced calls to openTransaction/commitTransaction" issue. I think
HIVE-8891 is slightly different from the issue here and it just ensures to
clean PersistenceManager cache after rollback to avoid the
NucleusObjectNotFoundException and should not involve in the nested txn count
issue.
Because rollbackTransaction always resets the openTransactionCalls to 0, so
even if you set the transactionStatus to TXN_STATUS.ROLLBACK regardless in
rollbackTrasaction, in the nested transaction example you gave above (e.g.
sqldirect fallback to jdo), the nested openTransaction following
rollbackTransaction will set it back to TXN_STATUS.OPEN, and patch provided
here would still not solve the issue for this example, is it right?
> ObjectStore:: rollbackTransaction() should set the transaction status to
> TXN_STATUS.ROLLBACK irrespective of whether it is active or not
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIVE-8850
> URL: https://issues.apache.org/jira/browse/HIVE-8850
> Project: Hive
> Issue Type: Bug
> Components: Metastore
> Reporter: Hari Sankar Sivarama Subramaniyan
> Assignee: Hari Sankar Sivarama Subramaniyan
> Attachments: HIVE-8850.1.patch
>
>
> We can run into issues as described below:
> Hive script adds 2800 partitions to a table and during this it can get a
> SQLState 08S01 [Communication Link Error] and bonecp kill all the connections
> in the pool. The partitions are added and a create table statement executes
> (Metering_IngestedData_Compressed). The map job finishes successfully and
> while moving the table to the hive warehouse the ObjectStore.java
> commitTransaction() raises the error: commitTransaction was called but
> openTransactionCalls = 0. This probably indicates that there are unbalanced
> calls to openTransaction/commitTransaction
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
