[
https://issues.apache.org/jira/browse/IGNITE-17856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17856:
-------------------------------------
Description:
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 should be updated
in a way similar to RO reads and scans were:
*Definition of Done*
{code:java}
Cursor<BinaryRow> scan(UUID txId) {code}
should be changed as follows
{code:java}
PartitionTimestampCursor scan(UUID txId) {code}
in order to produce an ability of definition whether the row is writeIntent or
not and reading latest non-intent row if the intent belongs to pending
transaction.
Same is about read operation.
{code:java}
BinaryRow read(RowId rowId, UUID txId) {code}
should be changed as follows
{code:java}
ReadResult read(RowId rowId, UUID txId) {code}
was:
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 should be updated
in a way similar to RO reads and scans were:
*Definition of Done*
{code:java}
Cursor<BinaryRow> scan(UUID txId) {code}
should be changed as follows
{code:java}
PartitionTimestampCursor scan(UUID txId) {code}
in order to produce an ability of definition whether the row is writeIntent or
not and reading latest non-intent row if the intent belongs to pending
transaction.
Same is about read operation.
{code:java}
BinaryRow read(RowId rowId, UUID txId) {code}
should be changed as follows
{code:java}
ReadResult read(RowId rowId, UUID txId) {code}
> 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
> 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 should be
> updated in a way similar to RO reads and scans were:
> *Definition of Done*
> {code:java}
> Cursor<BinaryRow> scan(UUID txId) {code}
> should be changed as follows
> {code:java}
> PartitionTimestampCursor scan(UUID txId) {code}
> in order to produce an ability of definition whether the row is writeIntent
> or not and reading latest non-intent row if the intent belongs to pending
> transaction.
> Same is about read operation.
> {code:java}
> BinaryRow read(RowId rowId, UUID txId) {code}
> should be changed as follows
> {code:java}
> ReadResult read(RowId rowId, UUID txId) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
