[jira] [Comment Edited] (IGNITE-7806) SQL TX: Backup update protocol

["Vladimir Ozerov (JIRA)" <ji...@apache.org>]

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

Vladimir Ozerov edited comment on IGNITE-7806 at 4/26/18 11:56 AM:
-------------------------------------------------------------------

[~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? 


was (Author: vozerov):
[~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)