[
https://issues.apache.org/jira/browse/HIVE-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Gates updated HIVE-10521:
------------------------------
Attachment: HIVE-10521.2.patch
Thanks [~ekoifman] for the review. You're right, having that commit in the
midst of the cursor is bad.
I am attaching a new patch that fixes this by removing the commit from
abortTxns(). The general rule in TxnHandler is that private methods don't do
commits, they leave that to the public/interface methods. timeOutTxns() now
violates that rule, but it explicitly calls that out in the comments. The
public method abortTxn() already does a commit after calling abortTxns() so now
both callers of abortTxns will handle the commit.
> TxnHandler.timeOutTxns only times out some of the expired transactions
> ----------------------------------------------------------------------
>
> Key: HIVE-10521
> URL: https://issues.apache.org/jira/browse/HIVE-10521
> Project: Hive
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 0.14.0, 1.0.0, 1.1.0
> Reporter: Alan Gates
> Assignee: Alan Gates
> Attachments: HIVE-10521.2.patch, HIVE-10521.patch
>
>
> {code}
> for (int i = 0; i < 20 && rs.next(); i++) deadTxns.add(rs.getLong(1));
> // We don't care whether all of the transactions get deleted or not,
> // if some didn't it most likely means someone else deleted them in the
> interum
> if (deadTxns.size() > 0) abortTxns(dbConn, deadTxns);
> {code}
> While it makes sense to limit the number of transactions aborted in one pass
> (since this get's translated to an IN clause) we should still make sure all
> are timed out. Also, 20 seems pretty small as a batch size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
