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

Kirill Tkalenko updated IGNITE-18322:
-------------------------------------
    Description: 
We need to define a contract for 
*org.apache.ignite.internal.storage.index.SortedIndexStorage#scan*, 
specifically how should we deal with concurrent storage updates?

For rocksDB, we have snapshot isolation defined, i.e. we will not see any 
parallel storage updates.

For BplusTree(PageMemory), we get the values in batches, we will take parallel 
storage updates only when the next batch is received.

It would be nice to define the general behavior of the scan, since we cannot 
implement snapshot isolation for a BplusTree(PageMemory), we can either leave 
it as it is or always get up-to-date rows.

It will be correct to receive the actual data, I will implement it.

  was:
We need to define a contract for 
*org.apache.ignite.internal.storage.index.SortedIndexStorage#scan*, 
specifically how should we deal with concurrent storage updates?

For rocksDB, we have snapshot isolation defined, i.e. we will not see any 
parallel storage updates.

For BplusTree(PageMemory), we get the values in batches, we will take parallel 
storage updates only when the next batch is received.

It would be nice to define the general behavior of the scan, since we cannot 
implement snapshot isolation for a BplusTree(PageMemory), we can either leave 
it as it is or always get up-to-date rows.


> Define scan contract SortedIndexStorage
> ---------------------------------------
>
>                 Key: IGNITE-18322
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18322
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Kirill Tkalenko
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>
> We need to define a contract for 
> *org.apache.ignite.internal.storage.index.SortedIndexStorage#scan*, 
> specifically how should we deal with concurrent storage updates?
> For rocksDB, we have snapshot isolation defined, i.e. we will not see any 
> parallel storage updates.
> For BplusTree(PageMemory), we get the values in batches, we will take 
> parallel storage updates only when the next batch is received.
> It would be nice to define the general behavior of the scan, since we cannot 
> implement snapshot isolation for a BplusTree(PageMemory), we can either leave 
> it as it is or always get up-to-date rows.
> It will be correct to receive the actual data, I will implement it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to