[
https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20894:
----------------------------------
Description:
h3. Motivation
The first purpose of the transaction flow tests is to preserve consistency in
storage. The reason for this might be partial commits due to executing commits
and rollbacks on one transaction. The second is avoiding redundant or permanent
locks that can originate from an asynchronous operation happening in parallel
with commit/rollback.
h3. Definition of done
Here is a list of tests that should be present:
# Multiple commits of the transaction from different threads. There should be
also some multithreaded enlists (via get/put operations) which should fail when
the finishing process of the transaction has started (transition to FINISHING
state is done). Such enlists should fail. After the completion of all
asynchronous operations there should be no locks left on server side.
# Same as 1, but there should be concurrent rollbacks instead of commits.
# Same as 1, but there should be random finish operations for transaction,
there can be commits after rollback and rollbacks after commit.
was:
h3. Motivation
The first purpose of the transaction flow tests is to preserve consistency in
storage. The reason for this might be partial commits due to executing commits
and rollbacks on one transaction. The second is avoiding redundant or permanent
locks that can originate from an asynchronous operation during a commit.
h3. Definition of done
Here is a list of tests that should be present:
# Ensure the correctness of the exception and all the transaction's locks are
freed when adding operations to a committed transaction. (Multithreading)
# Ensure the correctness of the exception and all the transaction's locks are
freed when adding operations to a rolled-back transaction. (Multithreading)
# Test consistency after commit when the transaction is acting asynchronously.
(1 and 2 about throwing an exception, 3 and 4 checks same invariants but for
not throwing an exception case.)
# Test consistency after rollback when the transaction is acting
asynchronously.
> Add tests for ensuring transactional guarantees
> -----------------------------------------------
>
> Key: IGNITE-20894
> URL: https://issues.apache.org/jira/browse/IGNITE-20894
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 3.0
> Reporter: Alexey Scherbakov
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> The first purpose of the transaction flow tests is to preserve consistency in
> storage. The reason for this might be partial commits due to executing
> commits and rollbacks on one transaction. The second is avoiding redundant or
> permanent locks that can originate from an asynchronous operation happening
> in parallel with commit/rollback.
> h3. Definition of done
> Here is a list of tests that should be present:
> # Multiple commits of the transaction from different threads. There should
> be also some multithreaded enlists (via get/put operations) which should fail
> when the finishing process of the transaction has started (transition to
> FINISHING state is done). Such enlists should fail. After the completion of
> all asynchronous operations there should be no locks left on server side.
> # Same as 1, but there should be concurrent rollbacks instead of commits.
> # Same as 1, but there should be random finish operations for transaction,
> there can be commits after rollback and rollbacks after commit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
