[
https://issues.apache.org/jira/browse/IGNITE-23603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-23603:
---------------------------------------
Description:
h3. Motivation
We are creating an implicit transaction through an internal API
(IgniteTransactionsImpl#beginImplicit). It is needed to distinguish observation
timestamps for multiple clients and embedded mode.
We do not use the API only for a client get-all request handler because we
cannot determine if the transaction can execute as a direct one (all keys in
the one partition) or not.
There are three ways we have:
# Use implicit RW transaction for batch read.
# Use implicit regular (not a direct one) RO transaction for batch read.
# Determine on the client side whether all keys are in one partition (start
implicit RO) or not (start implicit RW) and send another request type
(ClientOp#TUPLE_GET_DIRECT_ALL instead of common ClientOp#TUPLE_GET_ALL) to the
server side.
{code}
return readTableAsync(in, tables).thenCompose(table -> {
// TODO: IGNITE-23603 We have to create an implicit transaction, but leave
a possibility to start RO direct.
var tx = readTx(in, out, resources);
return readTuples(in, table, true).thenCompose(keyTuples -> {
return table.recordView().getAllAsync(tx, keyTuples).thenAccept(tuples
->
writeTuplesNullable(out, tuples, TuplePart.KEY_AND_VAL,
table.schemaView()));
});
});
{code}
h3. Definition of done
We start an implicit transaction for batch read for thinc client.
TODO that I left in ClientTupleGetAllRequest is removed.
was:
h3. Motivation
We are creating an implicit transaction through an internal API
(IgniteTransactionsImpl#beginImplicit). It is needed to distinguish observation
timestamps for multiple clients and embedded mode.
Unfortunately, this API is useless to create a direct RO transaction because
their logic works only if incomming transaction is null:
{code}
InternalTableImpl#get(org.apache.ignite.internal.schema.BinaryRowEx,
org.apache.ignite.internal.tx.InternalTransaction)
InternalTableImpl#getAll(java.util.Collection<org.apache.ignite.internal.schema.BinaryRowEx>,
org.apache.ignite.internal.tx.InternalTransaction)
{code}
h3. Definition of done
Add a possibility to create an implicit transaction for the RO direct.
This approach will be able to be used in ClientTupleGetAllRequest and
ClientTupleGetRequest (I left TODOs there).
> Implicit transaction for direct RO read
> ---------------------------------------
>
> Key: IGNITE-23603
> URL: https://issues.apache.org/jira/browse/IGNITE-23603
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We are creating an implicit transaction through an internal API
> (IgniteTransactionsImpl#beginImplicit). It is needed to distinguish
> observation timestamps for multiple clients and embedded mode.
> We do not use the API only for a client get-all request handler because we
> cannot determine if the transaction can execute as a direct one (all keys in
> the one partition) or not.
> There are three ways we have:
> # Use implicit RW transaction for batch read.
> # Use implicit regular (not a direct one) RO transaction for batch read.
> # Determine on the client side whether all keys are in one partition (start
> implicit RO) or not (start implicit RW) and send another request type
> (ClientOp#TUPLE_GET_DIRECT_ALL instead of common ClientOp#TUPLE_GET_ALL) to
> the server side.
> {code}
> return readTableAsync(in, tables).thenCompose(table -> {
> // TODO: IGNITE-23603 We have to create an implicit transaction, but
> leave a possibility to start RO direct.
> var tx = readTx(in, out, resources);
> return readTuples(in, table, true).thenCompose(keyTuples -> {
> return table.recordView().getAllAsync(tx,
> keyTuples).thenAccept(tuples ->
> writeTuplesNullable(out, tuples, TuplePart.KEY_AND_VAL,
> table.schemaView()));
> });
> });
> {code}
> h3. Definition of done
> We start an implicit transaction for batch read for thinc client.
> TODO that I left in ClientTupleGetAllRequest is removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
