ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Semen Boikov (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (IGNITE-4285) Optimize locks for read-only keys in optimistic/serializable transactions
Date Mon, 05 Dec 2016 10:45:58 GMT

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

Semen Boikov resolved IGNITE-4285.
    Resolution: Fixed

Implemented read locks optimization: for serializable txs lock candidate for 'read' can be
added in pedning queue without version check if before it there are only others 'read' lock
candidates. Locks re-assignment marks as owners all ready 'read' candidates in the queue head.

> Optimize locks for read-only keys in optimistic/serializable transactions
> -------------------------------------------------------------------------
>                 Key: IGNITE-4285
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4285
>             Project: Ignite
>          Issue Type: Task
>          Components: cache
>            Reporter: Semen Boikov
>            Assignee: Semen Boikov
>             Fix For: 2,0
> Currently, when optimistic transaction acquires lock for key which is not modified by
any other tx, TransactionOptimisticException is still possible if read lock has already been
acquired by any other tx with higher tx version.
> Following optimization is possible to avoid TransactionOptimisticException for mostly
read keys: when tx tries to add lock for 'read' key, and there are only 'read' locks in entry's
queue, then lock can be acquired immediately without tx version check. Standard version comparison
should still take place in case any writer is in queue which may result in optimistic exception.
> Having this implemented:
> # Ignite will not throw optimistic exception for read only keys
> # Ignite will be able to commit multiple transactions in parallel if these transactions
intersect only by their "reading" sets.

This message was sent by Atlassian JIRA

View raw message