Mailing-List: contact issues-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Date: Thu, 12 May 2016 09:14:12 +0000 (UTC)
From: "Denis Magda (JIRA)" <jira@apache.org>
To: issues@ignite.apache.org
Message-ID: <JIRA.12933020.1453366560000.173995.1463044452857@Atlassian.JIRA>
In-Reply-To: <JIRA.12933020.1453366560000@Atlassian.JIRA>
References: <JIRA.12933020.1453366560000@Atlassian.JIRA> <JIRA.12933020.1453366560396@arcas>
Subject: [jira] [Resolved] (IGNITE-2426) Document optimisitic
 (deadlock-free) transactions on readme.io
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 12 May 2016 09:14:14 -0000


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

Denis Magda resolved IGNITE-2426.
---------------------------------
    Resolution: Fixed

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