[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16858505#comment-16858505
]
Aleksey Plekhanov commented on IGNITE-5714:
-------------------------------------------
[~agoncharuk],
In the current Ignite transactions implementation single implicit transaction
has slightly different semantics when dealing with explicit locks, for example:
{code:java}
cache.lock(1).lock();
cache.put(1, 1);
{code}
This is a valid case for the implicit transaction, but this code:
{code:java}
cache.lock(1).lock();
Transaction tx = ignite.transactions().txStart();
cache.put(1, 1);
{code}
Will throw exception.
To keep such semantics we must check locks for implicit transactions by the
thread.
I will rename the method to {{isHeldByExplicitTx()}}.
About common semantics for XID and threads, there is already exists such
method: {{GridCacheMvccCandidate#isHeldByThreadOrVer}}, but it's not always
possible to use this method, for example, explicit locks don't have a XID, so
we can only check locks by thread here.
> Implementation of suspend/resume for pessimistic transactions
> -------------------------------------------------------------
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
> Issue Type: Sub-task
> Components: general
> Reporter: Alexey Kuznetsov
> Assignee: Aleksey Plekhanov
> Priority: Major
> Labels: iep-34
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Support transaction suspend()\resume() operations for pessimistic
> transactions. Resume can be called in another thread.
> _+But there is a problem+_: Imagine, we started pessimistic transaction in
> thread T1 and then perform put operation, which leads to sending
> GridDistributedLockRequest to another node. Lock request contains thread id
> of the transaction. Then we call suspend, resume in another thread and we
> also must send messages to other nodes to change thread id.
> It seems complicated task.It’s better to get rid of sending thread id to the
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
> _+Proposed solution+_ : On remote nodes instead of thread id of near
> transaction GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
