[
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 if
the finishing process of the transaction has already started (transition to
FINISHING state is done). After the completion of all asynchronous operations
there should be no locks left on server side (we should check that the failed
enlisting operations haven't left any locks as well).
# 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 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 if
the finishing process of the transaction has already started (transition to
FINISHING state is done). 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.
> 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
> if the finishing process of the transaction has already started (transition
> to FINISHING state is done). After the completion of all asynchronous
> operations there should be no locks left on server side (we should check that
> the failed enlisting operations haven't left any locks as well).
> # 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)
