ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denis Magda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-2426) Document optimisitic (deadlock-free) transactions on readme.io
Date Thu, 12 May 2016 09:14:12 GMT

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

Denis Magda commented on IGNITE-2426:

Documented in the following section

> 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

View raw message