You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexander Lapin (Jira)" <ji...@apache.org> on 2022/07/05 13:03:00 UTC
[jira] [Updated] (IGNITE-17309) Transactional support for partition scans
[ https://issues.apache.org/jira/browse/IGNITE-17309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Lapin updated IGNITE-17309:
-------------------------------------
Description:
It's required to add transactional support to
{code:java}
org.apache.ignite.internal.table.InternalTable#scan {code}
binding it to
{code:java}
org.apache.ignite.internal.storage.MvPartitionStorage#scan(java.util.function.Predicate<org.apache.ignite.internal.schema.BinaryRow>, java.util.UUID) {code}
along with acquiring corresponding locks, namely S_commit(table) - if a predicate can produce phantom reads, IS_commit(table) - otherwise.
Besides transactional support itself, it worth to ensure that scans together with other read commands don't linearized wihtin raft, meaning that raft in lease-based mode shouldn't perform read-index and thus properly perform multiple scans concurrently. If given assumption occurred to be incorrect it'll be required to re-implement scans in order to use storage directly without any raft interaction. It's possible because any RW-reads goes through PrimaryReplica that is guaranteed to be up-to-date. The only non-trivial moment here, is that according to raft paper storage itself isn't guaranteed to apply all commands up to commit index in a synchronous way, meaning that it's required to await for applyIndex to be greater or equal than commitIndex. IGNITE-16907 will introduce storage specific applied index, so that we should only extract commit index to replica somehow.
was:
It's required to add transactional support to
{code:java}
org.apache.ignite.internal.table.InternalTable#scan {code}
binding it to
{code:java}
org.apache.ignite.internal.storage.MvPartitionStorage#scan(java.util.function.Predicate<org.apache.ignite.internal.schema.BinaryRow>, java.util.UUID) {code}
along with acquiring corresponding locks, namely S_commit(table) - if a predicate can produce phantom reads, IS_commit(table) - otherwise.
Besides transactional support itself, it worth to ensure that scans together with other read commands don't linearized wihtin raft, meaning that raft in lease-based mode shouldn't perform read-index and thus properly perform multiple scans concurrently. If given assumption occurred to be incorrect it'll be required to re-implement scans in order to use storage directly without any raft interaction. It's possible because any RW-reads goes through PrimaryReplica that is guaranteed to be up-to-date. The only non-trivial moment here, is that according to raft paper storage itself isn't guaranteed to apply all commands up to commit index in a synchronous way, meaning that it's required to await for applyIndex to be greater or equal than commitIndex. IGNITE-16907 will introduce storage specific applied index, so that we should only extract commit index to replica somehow.
> Transactional support for partition scans
> -----------------------------------------
>
> Key: IGNITE-17309
> URL: https://issues.apache.org/jira/browse/IGNITE-17309
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3, transaction3_rw
>
> It's required to add transactional support to
> {code:java}
> org.apache.ignite.internal.table.InternalTable#scan {code}
> binding it to
> {code:java}
> org.apache.ignite.internal.storage.MvPartitionStorage#scan(java.util.function.Predicate<org.apache.ignite.internal.schema.BinaryRow>, java.util.UUID) {code}
> along with acquiring corresponding locks, namely S_commit(table) - if a predicate can produce phantom reads, IS_commit(table) - otherwise.
> Besides transactional support itself, it worth to ensure that scans together with other read commands don't linearized wihtin raft, meaning that raft in lease-based mode shouldn't perform read-index and thus properly perform multiple scans concurrently. If given assumption occurred to be incorrect it'll be required to re-implement scans in order to use storage directly without any raft interaction. It's possible because any RW-reads goes through PrimaryReplica that is guaranteed to be up-to-date. The only non-trivial moment here, is that according to raft paper storage itself isn't guaranteed to apply all commands up to commit index in a synchronous way, meaning that it's required to await for applyIndex to be greater or equal than commitIndex. IGNITE-16907 will introduce storage specific applied index, so that we should only extract commit index to replica somehow.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)