[
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)
