[
https://issues.apache.org/jira/browse/IGNITE-19388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718494#comment-17718494
]
Ignite TC Bot commented on IGNITE-19388:
----------------------------------------
{panel:title=Branch: [pull/10687/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10687/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7160253&buildTypeId=IgniteTests24Java8_RunAll]
> Reachless code of out-of-primary transaction locks.
> ---------------------------------------------------
>
> Key: IGNITE-19388
> URL: https://issues.apache.org/jira/browse/IGNITE-19388
> Project: Ignite
> Issue Type: Test
> Reporter: Vladimir Steshin
> Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> How can we request remote locks from a primary node with a transaction? Can
> we send GridDhtLockRequest and reply with GridDhtLockResponse? Any tests?
> We do:
> - Map transaction to primary nodes where locks actually occurs.
> - Remap transaction at the beginning if the topology changes.
> - Stop in-progress transaction if primary leaves.
> - Continue in-progress transaction if backup leaves.
> - Deprecate acquiring explicit locks within transaction.
>
> Technically, we attempt to send remote lock request further from primary
> (within transaction) when primary doesn't own partition. Probably if
> transaction starts at long rebalance?
>
> However, looks like such case is not covered by tests. I've run experimental
> PRs forcibly failing such remote lock processing within transaction. To be
> sure, in various ways. The test have passed. But they shouldn't have.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
