[ 
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781783#comment-16781783
 ] 

Ivan Pavlukhin commented on IGNITE-9470:
----------------------------------------

[~amashenkov], a particular test always goes in a following way: there are 2 
explicit transactions modifying the same key, and one of them always fails with 
_write conflict_ (the test simulates it). As a result there is only one 
transaction inserting new version of a key and all checks from multiple threads 
seem useless. I believe that the test was written in order to guarantee that 
initial implementation of MVCC for cache API (storing all entries in near tx) 
works as expected. And the test is rather fine-grained, I do not see it's value 
for current MVCC implementation. 

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

Reply via email to