ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Magda (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-2426) Document optimisitic (deadlock-free) transactions on readme.io
Date Thu, 21 Jan 2016 08:56:39 GMT
Denis Magda created IGNITE-2426:
-----------------------------------

             Summary: 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
            Reporter: Denis Magda
            Priority: Critical
             Fix For: 1.6


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)

Mime
View raw message