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

Eugene Koifman commented on HIVE-19340:
---------------------------------------

I think the logic is that if both source and target clusters are alive, the 2 
transactions should remain in the same state.
If source melts down, and abort is not propagated, we don't want the replicated 
txn to stay open forever so there should be some way (timeout or admin) way to 
kill it.
I suppose theoretically, the source may come back online with this txn still 
alive but on its aborted equivalent in target may have been GC'd by then.  Can 
replication handle this?  [~sershe] was this your concern?

> Disable timeout of transactions opened by replication task at target cluster
> ----------------------------------------------------------------------------
>
>                 Key: HIVE-19340
>                 URL: https://issues.apache.org/jira/browse/HIVE-19340
>             Project: Hive
>          Issue Type: Sub-task
>          Components: repl, Transactions
>    Affects Versions: 3.0.0
>            Reporter: mahesh kumar behera
>            Assignee: mahesh kumar behera
>            Priority: Major
>              Labels: ACID, DR, pull-request-available, replication
>             Fix For: 4.0.0
>
>         Attachments: HIVE-19340.01.patch, HIVE-19340.02.patch, 
> HIVE-19340.03-branch-3.patch, HIVE-19340.03.patch, 
> HIVE-19340.04-branch-3.patch
>
>
> The transactions opened by applying EVENT_OPEN_TXN should never be aborted 
> automatically due to time-out. Aborting of transaction started by replication 
> task may leads to inconsistent state at target which needs additional 
> overhead to clean-up. So, it is proposed to mark the transactions opened by 
> replication task as special ones and shouldn't be aborted if heart beat is 
> lost. This helps to ensure all ABORT and COMMIT events will always find the 
> corresponding txn at target to operate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to