[
https://issues.apache.org/jira/browse/IGNITE-20395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-20395:
-----------------------------------
Description:
If a transaction was committed/aborted, but for any reason the cleanup
operation was not performed on a node, the write intent entries would still be
present in the storage.
When an RO transaction sees such entries, no matter on primary or on any other
node, it performs write intent resolution and returns the correct result.
When an RW transaction sees write intents (happens on primary only), it also
performs write intent resolution. But any following change of the rows having
write intents will result in a storage exception because we don't support more
than one write intent per row.
IGNITE-20041 added a way to trigger async write intent cleanup on the node that
executes write intent resolution. But there are a few pieces left.
The cleanup operation after resolution is local, not distributed - if a primary
replica has been cleaned up, the other replicas will still have write intents
in their storages. Imagine the case when there are thee replicas, A, B and C. A
is primary.
A following RW transaction will successfully execute on primary since it had
its storage cleaned, but when replicating on B and C it will result in an
exception.
*We need to extend this functionality with the following(Definition of done):*
# If this is a primary replica and we are executing an RW transaction that has
already performed write intent resolution, we need to synchronously wait for a
pending cleanup of the affected rows to be able to safely change the storage.
# We need to perform the cleanup on all nodes of the replication group and
make sure RW transaction will synchronously wait for the corresponding cleanup
operation.
# Upsert operation does not read data, therefore will not perform resolution
and cleanup. Thus it may fail if there are unresolved intents in the storage.
Ensure upserts read data before inserting new.
was:
If a transaction was committed/aborted, but for any reason the cleanup
operation was not performed on a node, the write intent entries will still
present in the storage.
When an RO transaction sees such entries, no matter on primary or on any other
node, it performs write intent resolution and returns the correct result.
When an RW transaction sees write intents (happens on primary only), it also
performs write intent resolution. But any following change of the rows having
write intents will result in a storage exception because we don't support more
than one write intent per row.
IGNITE-20041 added a way to trigger async write intent cleanup on the node that
executes write intent resolution. But there are a few pieces left.
The cleanup operation after resolution is local, not distributed - if a primary
replica has been cleaned up, the other replicas will still have write intents
in their storages. Imagine the case when there are thee replicas, A, B and C. A
is primary.
A following RW transaction will successfully execute on primary since it had
its storage cleaned, but when replicating on B and C it will result in an
exception.
*We need to extend this functionality with the following(Definition of done):*
# If this is a primary replica and we are executing an RW transaction that has
already performed write intent resolution, we need to synchronously wait for a
pending cleanup of the affected rows to be able to safely change the storage.
# We need to perform the cleanup on all nodes of the replication group and
make sure RW transaction will synchronously wait for the corresponding cleanup
operation.
# Upsert operation does not read data, therefore will not perform resolution
and cleanup. Thus it may fail if there are unresolved intents in the storage.
Ensure upserts read data before inserting new.
> Make sure write intents are cleaned up for RW transaction
> ---------------------------------------------------------
>
> Key: IGNITE-20395
> URL: https://issues.apache.org/jira/browse/IGNITE-20395
> Project: Ignite
> Issue Type: Task
> Reporter: Kirill Sizov
> Priority: Major
> Labels: ignite-3
>
> If a transaction was committed/aborted, but for any reason the cleanup
> operation was not performed on a node, the write intent entries would still
> be present in the storage.
> When an RO transaction sees such entries, no matter on primary or on any
> other node, it performs write intent resolution and returns the correct
> result.
> When an RW transaction sees write intents (happens on primary only), it also
> performs write intent resolution. But any following change of the rows having
> write intents will result in a storage exception because we don't support
> more than one write intent per row.
> IGNITE-20041 added a way to trigger async write intent cleanup on the node
> that executes write intent resolution. But there are a few pieces left.
> The cleanup operation after resolution is local, not distributed - if a
> primary replica has been cleaned up, the other replicas will still have write
> intents in their storages. Imagine the case when there are thee replicas, A,
> B and C. A is primary.
> A following RW transaction will successfully execute on primary since it had
> its storage cleaned, but when replicating on B and C it will result in an
> exception.
> *We need to extend this functionality with the following(Definition of done):*
> # If this is a primary replica and we are executing an RW transaction that
> has already performed write intent resolution, we need to synchronously wait
> for a pending cleanup of the affected rows to be able to safely change the
> storage.
> # We need to perform the cleanup on all nodes of the replication group and
> make sure RW transaction will synchronously wait for the corresponding
> cleanup operation.
> # Upsert operation does not read data, therefore will not perform resolution
> and cleanup. Thus it may fail if there are unresolved intents in the storage.
> Ensure upserts read data before inserting new.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
