[ 
https://issues.apache.org/jira/browse/IGNITE-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453910#comment-16453910
 ] 

Vladimir Ozerov commented on IGNITE-7806:
-----------------------------------------

[~rkondakov],
1) GridCacheMapEntry.allVersionsInfo - appears to be wrong to me, because you 
set ttl, expireTime, ver, new and deleted flags from current entry, rather than 
specific version. All infos would have the same values of these properties. If 
these values are not needed fo MVCC case, may be it makes sense to introduce 
separate value object to transfer them? Or may be it doesn't make sense because 
AFAIK we are going to remove force keys request altogether soon. 
2) Message content looks less than optimal to me. Specifically:
- {{GridDhtTxQueryEnlistResponse}} may omit {{lockVer}} as it is already 
available on primary node
- after the first batch was sent to backup, there is no need to populate full 
{{GridDhtTxQueryEnlistRequest}} on next attempts - we only need to pass 
{{batchId}}, {{keys}}, {{vals}] and {{op}}, right?
3) {{GridDhtTransactionalCacheAdapter.processDhtTxQueryEnlistRequest0}} - does 
it make sense to group key-value pairs by partitions to minimize number of 
reservations? 

> 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)

Reply via email to