[ 
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.
 # 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). 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.


> 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.
>  # 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)

Reply via email to