[
https://issues.apache.org/jira/browse/IGNITE-20322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20322:
----------------------------------
Description:
*Motivation*
An implicit transaction is a transaction that is started by the table API when
a single operation is executed without specifying a transaction and committed
the operation is finished. Currently, implicit transactions use the common
observable timestamp. This timestamp is reserved for transactions started by
the embedded node only. That leads to unnecessary adjustments of the observable
timestamp (the timestamp is updated more often than required), that may have
serious performance impact on read-only transactions and read operations which
use implicit read-only transactions.
*Definition of done*
Implicit transactions should start with an observable timestamp that is
specific for each embedded server or for each client.
*Implementation notes*
On server side, thin client requests are handled by
ClientInboundMessageHandler, which uses public transaction API to deal with
transactions. However, observable timestamp shouldn't be a part of public API.
Within the scope of this ticket, we should extent internal transaction API in
order to:
* associate each client session with an instance of IgniteTransactions (which
already contains observable timestamp tracker);
* allow the client to update its observable timestamp tracker, for the cases
when client's observable timestamp is updated by responses from another server
node.
was:
*Motivation*
An implicit transaction is a transaction that is started by the table API when
a single operation is executed without specifying a transaction and committed
the operation is finished. Currently, implicit transactions use the common
observable timestamp. This timestamp is reserved for transactions started by
the embedded node only. That leads to unnecessary adjustments of the observable
timestamp (the timestamp is updated more often than required), that may have
serious performance impact on read-only transactions and read operations which
use implicit read-only transactions.
*Definition of done*
Implicit transactions should start with an observable timestamp that is
specific for each embedded server or for each client.
*Implementation notes*
On server side, thin client requests are handled by
ClientInboundMessageHandler. which uses public transaction API to deal with
transactions. However, observable timestamp shouldn't be a part of public API.
Within the scope of this ticket, we should extent internal transaction API in
order to:
* associate each client session with an instance of IgniteTransactions (which
already contains observable timestamp tracker);
* allow the client to update its observable timestamp tracker, for the cases
when client's observable timestamp is updated by responses from another server
node.
> Add ability to pass an observable timestamp to an implicit transaction
> ----------------------------------------------------------------------
>
> Key: IGNITE-20322
> URL: https://issues.apache.org/jira/browse/IGNITE-20322
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> *Motivation*
> An implicit transaction is a transaction that is started by the table API
> when a single operation is executed without specifying a transaction and
> committed the operation is finished. Currently, implicit transactions use the
> common observable timestamp. This timestamp is reserved for transactions
> started by the embedded node only. That leads to unnecessary adjustments of
> the observable timestamp (the timestamp is updated more often than required),
> that may have serious performance impact on read-only transactions and read
> operations which use implicit read-only transactions.
> *Definition of done*
> Implicit transactions should start with an observable timestamp that is
> specific for each embedded server or for each client.
> *Implementation notes*
> On server side, thin client requests are handled by
> ClientInboundMessageHandler, which uses public transaction API to deal with
> transactions. However, observable timestamp shouldn't be a part of public
> API. Within the scope of this ticket, we should extent internal transaction
> API in order to:
> * associate each client session with an instance of IgniteTransactions
> (which already contains observable timestamp tracker);
> * allow the client to update its observable timestamp tracker, for the cases
> when client's observable timestamp is updated by responses from another
> server node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
