[
https://issues.apache.org/jira/browse/IGNITE-20124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20124:
-------------------------------------
Description:
h3. Motivation
In order to preserve the guarantee that the primary replica is always
up-to-date it's required to:
* In case of common RW transaction - insert writeIntent to the storage within
primary before replication.
* In case of one-phase-commit - insert commitedWrite after the replication.
Both have already been done. However, that means that if primary is part of the
replication group, and it's true in almost all cases, we will double the insert:
* In case of common RW transaction - through the replication.
* In case of one-phase-commit - either through the replication, or though post
insert, if replication was fast enough.
h3. Definition of Done
* Prevent double storage updates within primary.
h3. Implementation Notes
The easiest way to prevent double insert is to skip one if local safe time is
greater or equal to candidates. There are 3 places where we update partition
storage:
# Primary pre-replication insert. In that case, it's never possible to see
already adjusted data.
# Primary post-replication insert in case of 1PC. It's possible to see already
inserted data if replication was already processed locally. It is expected to
be already covered in https://issues.apache.org/jira/browse/IGNITE-15927
# Insert through replication. In case of !1PC on every primary there will be
double insert. In case of 1PC it depends.
was:
h3. Motivation
In order to preserve the guarantee that the primary replica is always
up-to-date it's required to:
* In case of common RW transaction - insert writeIntent to the storage within
primary before replication.
* In case of one-phase-commit - insert commitedWrite after the replication.
Both have already been done. However, that means that if primary is part of the
replication group, and it's true in almost all cases, we will double the insert:
* In case of common RW transaction - through the replication.
* In case of one-phase-commit - either through the replication, or though post
insert, if replication was fast enough.
h3. Definition of Done
* Prevent re-insertion of data on the primer
> Prevent double storage updates within primary
> ---------------------------------------------
>
> Key: IGNITE-20124
> URL: https://issues.apache.org/jira/browse/IGNITE-20124
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3, transactions
>
> h3. Motivation
> In order to preserve the guarantee that the primary replica is always
> up-to-date it's required to:
> * In case of common RW transaction - insert writeIntent to the storage
> within primary before replication.
> * In case of one-phase-commit - insert commitedWrite after the replication.
> Both have already been done. However, that means that if primary is part of
> the replication group, and it's true in almost all cases, we will double the
> insert:
> * In case of common RW transaction - through the replication.
> * In case of one-phase-commit - either through the replication, or though
> post insert, if replication was fast enough.
> h3. Definition of Done
> * Prevent double storage updates within primary.
> h3. Implementation Notes
> The easiest way to prevent double insert is to skip one if local safe time is
> greater or equal to candidates. There are 3 places where we update partition
> storage:
> # Primary pre-replication insert. In that case, it's never possible to see
> already adjusted data.
> # Primary post-replication insert in case of 1PC. It's possible to see
> already inserted data if replication was already processed locally. It is
> expected to be already covered in
> https://issues.apache.org/jira/browse/IGNITE-15927
> # Insert through replication. In case of !1PC on every primary there will be
> double insert. In case of 1PC it depends.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
