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