[
https://issues.apache.org/jira/browse/HIVE-8850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215309#comment-14215309
]
Sushanth Sowmyan commented on HIVE-8850:
----------------------------------------
In theory, from analyzing the codeflow path of open and close transactions,
this looks like this is important to have. This is how I currently analyze the
flow of how the variable openTransactions is affected:
{noformat}
Methods that interact with openTransactions:
setConf
> instantiates it to 0 the very first time we start.
openTransaction
> Increments without any checks.
> If after incrementing, its value is 1, then sets currentTransaction =
pm.currentTransaction(), begins that trnasaction, and sests TXN_STATUS.OPEN
> If openTransactionCalls > 1, and current transaction is non-null and
active, all's good, returns
~ If openTransactionCalls > 1, but current transaction is null or
inactive, asserts (disabled in prod) but doesn't really handle anything.
rollbackTransaction
> If openTransactionCalls < 1, returns saying there's no open
transactions - from prior conditions, this can only happen if it's 0. Negative
cannot happen.
> sets openTransactionCalls to 0.
> if current transaction is inactive, does nothing
> If current transaction is active, and its status is
TXN_STATUS.ROLLBACK, does nothing
> If current transaction is active and its status is not
TXN_STATUS.ROLLBACK, then does the following:
+ sets status to TXN_STATUS.ROLLBACK
+ calls currentTransaction.rollback
+ calls pm.evictAll
~ If the transaction state goes inactive, we still have a case to
evict, and that is what's being done in this patch.
commitTransaction
> If current state is TXN_STATUS.ROLLBACK, returns false
> If openTransactionCalls is <=0, errors out about unbalanced
commitTransactions.
> Technically, this can never be negative, it can only happen
if it is 0.
> Also, the only cases that lead to this state are if:
a) More commitTransactions are called than the number
of openTransactions that were called.
b) rollbackTransaction was called, but for whatever
reason, did not set TXN_STATUS.ROLLBACK, followed by calling commitTransaction
later.
- note that this can happen if the current
transaction should become invalid for whatever reason before rollback is
called. There does seem to be an issue here, in that rollback will not result
in a full eviction in this case, but atleast we error here in a valid way.
> If current transaction is not active, throws an error identical to
the previous case. This is probably not good if we need to ever distinguish
between these two cases, and if the current transaction might wind up being
inactive for whatever other reason.
> decrements if it should apply successfully.
> If the result of the decrement gets it to 0, and current transaction
is active, then commits the current transaction, and ssets status to
TXN_STATUS.COMMITTED
{noformat}
So, it would seem that this patch is correct and needed. However, since this is
a sensitive area, I'm trying to follow call stacks to rollback and commit
transaction to make sure I'm not misreading this.
> 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)
