[
https://issues.apache.org/jira/browse/IGNITE-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16457459#comment-16457459
]
Roman Kondakov commented on IGNITE-7806:
----------------------------------------
[~vozerov],
1. Fixed.
2. I've removed {{lockVer}} from {{GridDhtTxQueryEnlistResponse}}. I've also
added {{GridDhtTxQueryFirstEnlistRequest}} which is sent with a very first
keys-values batch to backups and cleaned up {{GridDhtTxQueryEnlistRequest}}
where all extra fields were removed.
3. After the small investigation I've found out that for the remote
transactions partititions are always reserved for each each key during entry
processing. See {{GridDhtTransactionalCacheAdapter#startRemoteTx}} and \{{
IgniteTxHandler#startRemoteTx}}. Partition reservation is a {{long}} CAS, so
it's not an expensive operation. I left reservations as is and didn't rework it
here.
> SQL TX: Backup update protocol
> ------------------------------
>
> Key: IGNITE-7806
> URL: https://issues.apache.org/jira/browse/IGNITE-7806
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
> Reporter: Vladimir Ozerov
> Assignee: Roman Kondakov
> Priority: Major
> Fix For: 2.6
>
>
> Currently TX SQL protocol works as follows:
> 1) Lock request is sent to {{PRIMARY}} node where updates are applied
> immediately.
> 2) Updated values are stored in-memory
> 3) When commit command is issued, updates are propagated to {{BACKUP}}s.
> This requires data to be stored in memory at some point. We should design
> better protocol which will allow for updates to be propagated to backups
> efficiently.
> Ticket is related (or may be even duplicates) to IGNITE-7186.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
