[
https://issues.apache.org/jira/browse/IGNITE-19900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-19900:
-------------------------------------
Description:
h3. Motivation
RW TX protocol requires commit timestamp to be greater than all other
timestamps associated with previous TX actions of the same transaction. For
more details, please check
[IEP-91:Hybridlogicaltime|#IEP91:Transactionprotocol-Hybridlogicaltime].].
Thus, any TX request/response up to the commit timestamp generation transfers a
hybrid timestamp from one TX actor to another, where another actor adjust its
HLC as
{code:java}
max(requestTime.longValue() + 1, max(now, oldLatestTime + 1));{code}
See
{code:java}
org.apache.ignite.internal.replicator.message.TimestampAware{code}
and
{code:java}
org.apache.ignite.internal.hlc.HybridClockImpl#update{code}
for more details.
Given logic was already implemented for server-side communication and thus
should only be expanded to the client side, so that clients can route TX
requests themselves for the best-effort affinity purposes. It is worth to
mention that client won't have HLC instance itself, because it's not possible
to cover clients with clock skew management, thus it will only store timestamp
received from the server and send it back with RW/RO requests. Client-server
protocol adjustments (adding hybridTimestamp field to both requests and
response together storing logic) will be implemented in
https://issues.apache.org/jira/browse/IGNITE-19884 along with propagating
commitTimestmap and RO.readTimestamp to the client, meaning that withing
current ticket it'll be necessary:
* To expand list of such server-to-client TX-related timestamp producers, in a
way that *all* RW TX responses, that were triggered from client, will propagate
corresponding response timestamps to a client.
* Timestamp retrieved from the client wihtin the scope of RW TX flow will
adjust server HLC.
h3. Definition of Done
* The HLC adjustment on the server actors of the RW TX protocol is also
available in cases of their communication transitively through the client.
was:
h3. Motivation
RW tx protocol requires commit timestamp to be greater than all other
timestamps assosiated with previous tx actions of the same transacions. For
more details prease check
[IEP-91:Hybridlogicaltime|[https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Hybridlogicaltime].]
Thus any tx request/response up to the commit timestamp generation transfers
hybrid timestamp from one tx actor to another, where another actor adjust its
HLC as
{code:java}
max(requestTime.longValue() + 1, max(now, oldLatestTime + 1));{code}
See org.apache.ignite.internal.replicator.message.TimestampAware and
{code:java}
org.apache.ignite.internal.hlc.HybridClockImpl#update{code}
for more details
> Server nodes should both propagate and handle HLC timestamps to/from clients
> within tx RW protocol
> --------------------------------------------------------------------------------------------------
>
> Key: IGNITE-19900
> URL: https://issues.apache.org/jira/browse/IGNITE-19900
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
>
> h3. Motivation
> RW TX protocol requires commit timestamp to be greater than all other
> timestamps associated with previous TX actions of the same transaction. For
> more details, please check
> [IEP-91:Hybridlogicaltime|#IEP91:Transactionprotocol-Hybridlogicaltime].].
> Thus, any TX request/response up to the commit timestamp generation transfers
> a hybrid timestamp from one TX actor to another, where another actor adjust
> its HLC as
> {code:java}
> max(requestTime.longValue() + 1, max(now, oldLatestTime + 1));{code}
> See
> {code:java}
> org.apache.ignite.internal.replicator.message.TimestampAware{code}
> and
>
> {code:java}
> org.apache.ignite.internal.hlc.HybridClockImpl#update{code}
> for more details.
> Given logic was already implemented for server-side communication and thus
> should only be expanded to the client side, so that clients can route TX
> requests themselves for the best-effort affinity purposes. It is worth to
> mention that client won't have HLC instance itself, because it's not possible
> to cover clients with clock skew management, thus it will only store
> timestamp received from the server and send it back with RW/RO requests.
> Client-server protocol adjustments (adding hybridTimestamp field to both
> requests and response together storing logic) will be implemented in
> https://issues.apache.org/jira/browse/IGNITE-19884 along with propagating
> commitTimestmap and RO.readTimestamp to the client, meaning that withing
> current ticket it'll be necessary:
> * To expand list of such server-to-client TX-related timestamp producers, in
> a way that *all* RW TX responses, that were triggered from client, will
> propagate corresponding response timestamps to a client.
> * Timestamp retrieved from the client wihtin the scope of RW TX flow will
> adjust server HLC.
> h3. Definition of Done
> * The HLC adjustment on the server actors of the RW TX protocol is also
> available in cases of their communication transitively through the client.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
