[
https://issues.apache.org/jira/browse/HIVE-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524394#comment-14524394
]
Alan Gates commented on HIVE-10521:
-----------------------------------
What I'm concerned about is the pathological case where a user has somehow
managed to accrue thousands of open transactions (I've seen our QE achieve this
a few times). Then the delete statement will be too large to parse and will
die. And worse, there's then no good way forward since all attempts to start
queries will die once the user is in this situation. 99.99% of the time we
shouldn't have more than 100 open transactions to time out anyway, so we
shouldn't generally go through the loop more than once.
> 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.3.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)
