[ 
https://issues.apache.org/jira/browse/IGNITE-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda closed IGNITE-2426.
-------------------------------

> Document optimisitic (deadlock-free) transactions on readme.io
> --------------------------------------------------------------
>
>                 Key: IGNITE-2426
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2426
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 1.5.0.final
>            Reporter: Denis Magda
>            Priority: Critical
>              Labels: important
>             Fix For: 1.6
>
>         Attachments: TransactionTest.java
>
>
> There is a lack of documentation on how optimistic & serializable 
> transactions work.
> Basic documentation has to be added covering some specific cases in addition.
> As an example, the test attached demonstrates the following.
> Both tasks update cache with put operations only without reading and keeping 
> entries's versions cause there is no any cache.get/getAll calls as a part of 
> the transaction.
> Each transaction has it's unique ID. So at the commit time when one 
> transaction B tries to update an entry locking it before and sees that the 
> entry is locked by some transaction A, started earlier (have smaller 
> transaction ID), then transaction B will just wait until the lock is released 
> and can proceed with the commit later. If this repeats for every entry of 
> transactions and we haven't detected any conflict then both transactions 
> succeeds. This is exactly what happens sometimes in your test.
> However, if the transactions were using cache.get or related operations then 
> during the commit time both transactions would be checking entry versions in 
> addition before proceeding with the commit. In general if an entry version at 
> commit time is different to the entry version at get time then a transaction 
> fails. To see this in practice use cache.getAndPut() instead of cache.put() 
> in the code. After applying this modification one of the transactions will 
> always fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to