[
https://issues.apache.org/jira/browse/HIVE-11833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated HIVE-11833:
------------------------------------
Description:
What it does is:
1) Blindly update lock heartbeat time, fails if not found.
2) Get txn state.
3) If not found, look for txn in completed, fails regardless of result.
4) Update txn heartbeat time if not (3) and not aborted.
All this can run the same under repeatable-reads.
Now if it runs under read-committed, someone could
1) update txn state after we read it
2) delete txn state (moving to completed) after we read it
3) same for completed state
In case of 1 we will update heartbeat for e.g. aborted txn without detecting
it. UPD: We can change queries to detect it
In case of 2 the update will produce 0 rows so we will detect that and can
check completed as we already do.
The 3 case seems like it doesn't matter.
I don't know if (1) matters. These heartbeats happen often and can cause
contention on the db
was:
What it does is:
1) Blindly update lock heartbeat time, fails if not found.
2) Get txn state.
3) If not found, look for txn in completed, fails regardless of result.
4) Update txn heartbeat time if not (3) and not aborted.
All this can run the same under repeatable-reads.
Now if it runs under read-committed, someone could
1) update txn state after we read it
2) delete txn state (moving to completed) after we read it
3) same for completed state
In case of 1 we will update heartbeat for e.g. aborted txn without detecting it.
In case of 2 the update will produce 0 rows so we will detect that and can
check completed as we already do.
The 3 case seems like it doesn't matter.
I don't know if (1) matters. These heartbeats happen often and can cause
contention on the db
> TxnHandler heartbeat txn doesn't need to serializable DB txn level
> ------------------------------------------------------------------
>
> Key: HIVE-11833
> URL: https://issues.apache.org/jira/browse/HIVE-11833
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HIVE-11833.patch
>
>
> What it does is:
> 1) Blindly update lock heartbeat time, fails if not found.
> 2) Get txn state.
> 3) If not found, look for txn in completed, fails regardless of result.
> 4) Update txn heartbeat time if not (3) and not aborted.
> All this can run the same under repeatable-reads.
> Now if it runs under read-committed, someone could
> 1) update txn state after we read it
> 2) delete txn state (moving to completed) after we read it
> 3) same for completed state
> In case of 1 we will update heartbeat for e.g. aborted txn without detecting
> it. UPD: We can change queries to detect it
> In case of 2 the update will produce 0 rows so we will detect that and can
> check completed as we already do.
> The 3 case seems like it doesn't matter.
> I don't know if (1) matters. These heartbeats happen often and can cause
> contention on the db
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
