[
https://issues.apache.org/jira/browse/IGNITE-17856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-17856:
----------------------------------------
Assignee: Alexander Lapin
> MvPartitionStorage#scan(UUID) and read(UUID) should return
> PartitionTimestampCursor and ReadResult
> --------------------------------------------------------------------------------------------------
>
> Key: IGNITE-17856
> URL: https://issues.apache.org/jira/browse/IGNITE-17856
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Tx protocol design assumes that data entry exists in the form of a _write
> intent_ from the moment the entry is changed within transaction to the moment
> it is either converted to the regular value or removed during tx cleanup
> phase.
> Read Only transactions because of their lock-less nature may see such
> writeIntents (corresponding changes were implemented within IGNITE-17720 and
> IGNITE-17627) and ...
> ... according to tx design updates so does Read Write transactions.
> Let's clarify this in greater detail:
> * Originally tx finish process firstly converted the write intents into
> regular values, and only then released the locks. Thus, other RW transactions
> could never see write intents as they were always waiting for locks to be
> released.
> * In the current version of the [TX
> IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol],
> the order has been changed to the opposite: locks are released before write
> Intents conversion, so that not only a RO but also a RW transactions may see
> the intents.
> All in all, that means that both read and scan RW operations may use
> timestamp based reads and scans with a properly distant timestamp in the
> future.
> *Definition of Done*
> {code:java}
> Cursor<BinaryRow> scan(UUID txId) {code}
> and
> {code:java}
> BinaryRow read(RowId rowId, UUID txId) {code}
> should be removed.
> {code:java}
> PartitionTimestampCursor scan(HybridTimestamp timestamp) {code}
> and
> {code:java}
> ReadResult read(RowId rowId, HybridTimestamp timestamp) {code}
> should be used instead.
> h3. Implementation notes
> Solution is pretty straight forward
> * Removing deprecated methods along with underneath implementations.
> * Propagating RW reads and scans to timestamp based MvPartitionStorage reads
> and scans with some sort of HybridTimestamp.MAX_VALUE as a timestamp paramter.
> * Verifying that within RW transactions returned ReadResults contain values
> with matching txIds (see TxIdMismatchException). That should be guaranteed by
> locks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
