[
https://issues.apache.org/jira/browse/IGNITE-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-16723:
-----------------------------------
Description:
Need to investigate:
# how it is guaranteed that the commit timestamp is in the leaseholder
intervals of all enlisted partitions in case of a failure of txn enlisted
leaseholder.
# how to restore a lock for a read operation in case of a failure of txn
enlisted leaseholder.
For example:
tx1.start
v1 = tx1.read(k1) in range1
tx1.write(k2, v1) in range2
Start to commit tx1 (the write intent was replicated, a commit timestamp known,
but a commit request was not sent yet)
Leaseholder of range1 has failed, the lease has expired. A new leaseholder was
elected.
tx2.start
tx2.write(k1, v2) in range1
tx2.commit
tx2.end
Transaction record of tx1 is committed now.
tx1.end
I started a topic with a discussion of this example on the CocroachDB forum
https://forum.cockroachlabs.com/t/read-write-tx-conflicts-on-leaseholder-failover/5213
was:
Need to investigate:
# how it is guaranteed that the commit timestamp is in the leaseholder
intervals of all enlisted partitions in case of a failure of txn enlisted
leaseholder.
# how to restore a lock for a read operation in case of a failure of txn
enlisted leaseholder.
For example:
tx1.start
v1 = tx1.read(k1) in range1
tx1.write(k2, v1) in range2
Start to commit tx1 (the write intent was replicated, a commit timestamp known,
but a commit request was not sent yet)
Leaseholder of range1 has failed, the lease has expired. A new leaseholder was
elected.
tx2.start
tx2.write(k1, v2) in range1
tx2.commit
tx2.end
Transaction record of tx1 is committed now.
tx1.end
> TX Recovery protocol in Cockroach in case of a failure of enlisted leaseholder
> ------------------------------------------------------------------------------
>
> Key: IGNITE-16723
> URL: https://issues.apache.org/jira/browse/IGNITE-16723
> Project: Ignite
> Issue Type: Task
> Reporter: Sergey Uttsel
> Assignee: Sergey Uttsel
> Priority: Major
> Labels: ignite-3
>
> Need to investigate:
> # how it is guaranteed that the commit timestamp is in the leaseholder
> intervals of all enlisted partitions in case of a failure of txn enlisted
> leaseholder.
> # how to restore a lock for a read operation in case of a failure of txn
> enlisted leaseholder.
>
> For example:
> tx1.start
> v1 = tx1.read(k1) in range1
> tx1.write(k2, v1) in range2
> Start to commit tx1 (the write intent was replicated, a commit timestamp
> known, but a commit request was not sent yet)
> Leaseholder of range1 has failed, the lease has expired. A new leaseholder
> was elected.
> tx2.start
> tx2.write(k1, v2) in range1
> tx2.commit
> tx2.end
> Transaction record of tx1 is committed now.
> tx1.end
>
> I started a topic with a discussion of this example on the CocroachDB forum
> https://forum.cockroachlabs.com/t/read-write-tx-conflicts-on-leaseholder-failover/5213
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
