[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774297#comment-16774297
]
Andrew Mashenkov commented on IGNITE-9470:
------------------------------------------
[~Pavlukhin], I've some comment to the PR.
# IndexingSPI doesn't support mvcc. Let's create a ticket to rework public
interface and remute failed tests.
For now, I'd add IndexingSPI checks into cache validation procedure and forbid
it's usage.
# CachePredicate is for internal usage only and it can't threw any exception.
Let's remove 'mockEntryPredicate' and revert changes in test. Moreover this
change overlap IndexingSPI failover.
# Next check looks useless as class childs can be moved to Mvcc suite.
{noformat}
@Before
public void ensureForcedMvcc() {
assert MvccFeatureChecker.forcedMvcc();
}
{noformat}
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --------------------------------------------------------------------------
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
> Reporter: Roman Kondakov
> Assignee: Ivan Pavlukhin
> Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
> Pay attention that tx could be aborted at different stages, but we should
> fail consistently. Some examples:
> 1. Before next operation in tx started.
> 2. While operation in tx is in progress.
> 3. When {{tx.commit()}} is called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
