[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, 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 introduce direct storage reads from within PrimaryReplica instead of going through raft. 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, java.util.UUID) {code} along with acquiring corresponding locks, namely S_commit(table) - if a predicate can produce phantom reads, IS_commit(table) - otherwise. > 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, > 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 introduce direct storage > reads from within PrimaryReplica instead of going through raft. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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, java.util.UUID) {code} along with acquiring corresponding locks, namely S_commit(table) - if a predicate can produce phantom reads, IS_commit(table) - otherwise. 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, 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, > java.util.UUID) {code} > along with acquiring corresponding locks, namely S_commit(table) - if a > predicate can produce phantom reads, IS_commit(table) - otherwise. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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, 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, 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, > 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)