[jira] [Updated] (IGNITE-17627) Extend MvPartitionStorage API with write intent resolution capabilities

["Semyon Danilov (Jira)" <ji...@apache.org>]

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

Semyon Danilov updated IGNITE-17627:
------------------------------------
    Description: 
Commit of RW transaction is not instantaneous. RO transaction might require reads of data that's in the process of being committed. Current API doesn't support such scenario.

RO API in partition storage has only two methods: {{read}} and {{{}scan{}}}.
h3. Read

This one is pretty simple. It should return pair of {{binaryRow}} and {{{}txId{}}}. After that, caller can check the state of the transaction and either return the value or repeat the call.

There must be a way to hint read method that uncommitted data must be skipped.

An interesting way of reading data might be required: it there's a write intent, but we see a commit done after the timestamp, we can safely proceed with reading.

Unfortunately, such optimization may be heavy on the storage read operations, because it requires a "deep" look-ahead request. So, whether or not we implement this depends on one thing - how often do we have write intent resolution in real RO transactions?

API is to be defined.

For scans see https://issues.apache.org/jira/browse/IGNITE-17720

  was:
Commit of RW transaction is not instantaneous. RO transaction might require reads of data that's in the process of being committed. Current API doesn't support such scenario.

RO API in partition storage has only two methods: {{read}} and {{{}scan{}}}.
h3. Read

This one is pretty simple. It should return pair of {{binaryRow}} and {{{}txId{}}}. After that, caller can check the state of the transaction and either return the value or repeat the call.

There must be a way to hint read method that uncommitted data must be skipped.

An interesting way of reading data might be required: it there's a write intent, but we see a commit done after the timestamp, we can safely proceed with reading.

Unfortunately, such optimization may be heavy on the storage read operations, because it requires a "deep" look-ahead request. So, whether or not we implement this depends on one thing - how often do we have write intent resolution in real RO transactions?

API is to be defined.
h3. Scan

This one is tricky, we can't just return a cursor. Special type of cursor is required, and it must allow same read capabilities on each individual element.

API is to be defined.


> Extend MvPartitionStorage API with write intent resolution capabilities
> -----------------------------------------------------------------------
>
>                 Key: IGNITE-17627
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17627
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Ivan Bessonov
>            Assignee: Semyon Danilov
>            Priority: Major
>              Labels: ignite-3
>
> Commit of RW transaction is not instantaneous. RO transaction might require reads of data that's in the process of being committed. Current API doesn't support such scenario.
> RO API in partition storage has only two methods: {{read}} and {{{}scan{}}}.
> h3. Read
> This one is pretty simple. It should return pair of {{binaryRow}} and {{{}txId{}}}. After that, caller can check the state of the transaction and either return the value or repeat the call.
> There must be a way to hint read method that uncommitted data must be skipped.
> An interesting way of reading data might be required: it there's a write intent, but we see a commit done after the timestamp, we can safely proceed with reading.
> Unfortunately, such optimization may be heavy on the storage read operations, because it requires a "deep" look-ahead request. So, whether or not we implement this depends on one thing - how often do we have write intent resolution in real RO transactions?
> API is to be defined.
> For scans see https://issues.apache.org/jira/browse/IGNITE-17720



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