[
https://issues.apache.org/jira/browse/IGNITE-24142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-24142:
---------------------------------------
Description:
Client transactions are lazy. This means that a client RO transaction
establishes its readTs on first data node access, not on start. But in the
embedded mode, readTs is established on transaction start.
# It seems weird that our APIs behave differently
# Trying to imagine myself in the user's shoes, it seems very counterintuitive
that creation of a transaction does not establish the readTs. Take a look at
the reproducer scenario: as a user, I would expect the test to pass in both
cases (embedded/client)
Attaching a reproducer. It passes for embedded mode but fails for client. The
scenario is:
# Start an RO tx (tx1)
# Make an implicit put under k1
# Read k1 in tx1 and expect to see nothing
was:
Client transactions are lazy. This means that a client RO transaction
establishes its readTs on first data node access, not on start. But in the
embedded mode, readTs is established on transaction start.
# It seems weird that our APIs behave differently
# Trying to imagine myself in the user's shoes, it seems very counterintuivite
that creation of a transaction does not establish the readTs. Take a look at
the reproducer scenario: as a user, I would expect the test to pass in both
cases (embedded/client)
Attaching a reproducer. It passes for embedded mode but fails for client. The
scenario is:
# Start an RO tx (tx1)
# Make an implicit put under k1
# Read k1 in tx1 and expect to see nothing
> RO transactions establish readTs on first read and not on start
> ---------------------------------------------------------------
>
> Key: IGNITE-24142
> URL: https://issues.apache.org/jira/browse/IGNITE-24142
> Project: Ignite
> Issue Type: Bug
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Attachments: ItReadOnlyTxStartTest.java
>
>
> Client transactions are lazy. This means that a client RO transaction
> establishes its readTs on first data node access, not on start. But in the
> embedded mode, readTs is established on transaction start.
> # It seems weird that our APIs behave differently
> # Trying to imagine myself in the user's shoes, it seems very
> counterintuitive that creation of a transaction does not establish the
> readTs. Take a look at the reproducer scenario: as a user, I would expect the
> test to pass in both cases (embedded/client)
> Attaching a reproducer. It passes for embedded mode but fails for client. The
> scenario is:
> # Start an RO tx (tx1)
> # Make an implicit put under k1
> # Read k1 in tx1 and expect to see nothing
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
