[
https://issues.apache.org/jira/browse/IGNITE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Zhdanov updated IGNITE-4285:
----------------------------------
Description:
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.
was:
Now when optimistic transaction acquires lock for key which is not modified by
any other tx, then TransactionOptimisticException is still possible if read
lock is already held by some other tx with higher tx version.
Following optimziation is possible to avoid TransactionOptimisticException for
mostly read keys: when try to add lock for 'read' key, and in locks queue there
are only others 'read' locks, then lock can be acquired immediately without tx
version check.
> 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
(v6.3.4#6332)
