[
https://issues.apache.org/jira/browse/IGNITE-23980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-23980:
---------------------------------------
Description:
h3.Motivation
We should not execute any operation if the transaction was committed. It is
true for RW transactions, but RO can be used after their state has been
finalized. Dispite internla transaction state is final
(ReadOnlyTransactionImpl#finishGuard == true) we do not check it in operation
(look into InternalTableImpl#get(key, tx)).
Any operation cannot be processed for a committed/rolled-back RW transaction
because we are checking the transaction state during enlist
(ReadWriteTransactionImpl#enlist()).
h3.Definition of done
* We have to have similar behavior for RO as for RW.
* We ought to exclude process operations (get/getAll) in committed/rolled-back
RO in the single thread case at least.
* We need to reject SQL operations in committed/rolled-back RO.
was:
After a transaction (either RW or RO) is completed, no operations
(reads/writes) in this transaction should be allowed. (This is currently
violated at least for RO transactions)
Also, a commit should not be able after an abort and vice versa.
> Fail operations in a completed transaction
> ------------------------------------------
>
> Key: IGNITE-23980
> URL: https://issues.apache.org/jira/browse/IGNITE-23980
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> h3.Motivation
> We should not execute any operation if the transaction was committed. It is
> true for RW transactions, but RO can be used after their state has been
> finalized. Dispite internla transaction state is final
> (ReadOnlyTransactionImpl#finishGuard == true) we do not check it in operation
> (look into InternalTableImpl#get(key, tx)).
> Any operation cannot be processed for a committed/rolled-back RW transaction
> because we are checking the transaction state during enlist
> (ReadWriteTransactionImpl#enlist()).
> h3.Definition of done
> * We have to have similar behavior for RO as for RW.
> * We ought to exclude process operations (get/getAll) in
> committed/rolled-back RO in the single thread case at least.
> * We need to reject SQL operations in committed/rolled-back RO.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
