[
https://issues.apache.org/jira/browse/IGNITE-17963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17963:
-------------------------------------
Description:
h3. Motivation
It's possible for an end user to run read-only reads using KeyValueView and
RecordView endpoints with the help of get(), getAll() and similar methods
propagating read-only transaction as a first parameter. Internally such
requests will be routed to some recipient node that will process given reads.
Despite read-write actions that are processed on primary replica only, it's
possible to handle read-only actions on any replica of a corresponding
replication group. Thus some internal processor should define a node that will
process read-only action. Currently primary replica is always selected, so that
it's required to upgrade read-only recipient node evaluator with some smarter
logic. As a starting point we may consider local read-result processing as
preferable.
h3. Definition of Done
KeyValueView and RecordView read-only reads processed locally if there's a
local replica of a corresponding group.
h3. Implementation Notes
Generally speaking we should try to reuse sql engine logic here. Probably it'll
lead to exacting some sort of common planner for all table access endpoints.
However it might be rather tough improvement to implement, so within the scope
of given ticket let's do some initial research of how sql engine targets
requests to the nodes and add locality based recipient node evaluation.
Currently it's all about InternalTableImpl#evaluateReadOnlyRecipientNode
was:
h3. Motivation
It's required to add an ability for the end user to run RO transactions from
within both KeyValueView and RecordView. IgniteTransactions already provide an
ability to start RO transactions, meaning that it's only required to propagate
InternalTable get(), getAll() and scan() to corresponding readTimestamp-based
get(), getAll() and scan() methods.
h3. Definition of Done
It's possible to trigger read-only get and getAll and scan by calling
> Use smarter logic for read-only recipient node evaluation
> ---------------------------------------------------------
>
> Key: IGNITE-17963
> URL: https://issues.apache.org/jira/browse/IGNITE-17963
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
>
> h3. Motivation
> It's possible for an end user to run read-only reads using KeyValueView and
> RecordView endpoints with the help of get(), getAll() and similar methods
> propagating read-only transaction as a first parameter. Internally such
> requests will be routed to some recipient node that will process given
> reads. Despite read-write actions that are processed on primary replica only,
> it's possible to handle read-only actions on any replica of a corresponding
> replication group. Thus some internal processor should define a node that
> will process read-only action. Currently primary replica is always selected,
> so that it's required to upgrade read-only recipient node evaluator with some
> smarter logic. As a starting point we may consider local read-result
> processing as preferable.
> h3. Definition of Done
> KeyValueView and RecordView read-only reads processed locally if there's a
> local replica of a corresponding group.
> h3. Implementation Notes
> Generally speaking we should try to reuse sql engine logic here. Probably
> it'll lead to exacting some sort of common planner for all table access
> endpoints. However it might be rather tough improvement to implement, so
> within the scope of given ticket let's do some initial research of how sql
> engine targets requests to the nodes and add locality based recipient node
> evaluation.
> Currently it's all about InternalTableImpl#evaluateReadOnlyRecipientNode
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
