You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2024/12/30 08:15:00 UTC

[jira] [Updated] (IGNITE-24142) RO transactions establish readTs on first read and not on start

     [ 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 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
>
> 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



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