1) The essential problem lies in *IgniteTxAdapter#threadId*.
Thread id is set when transaction is created and afterwards is transferred
between nodes by GridDistributedTx requests\responses
when we perform put\get operations.
When we suspend and resume transaction, thread id is got changed locally,
Hello, Alexey.
Could you please, write little more about your implementation
1. Design of implementation.
2. Advantages of you implementation in compare with other ways?
3. Transactions performance penalties/improvements?
В Вт, 13/02/2018 в 14:17 +, ALEKSEY KUZNETSOV пишет:
> Hi, Igniters
Hi, Igniters!
Currently we have context switching implemented for optimistic
transactions [1].
Goal of the current ticket is to support transaction suspend()\resume()
operations for pessimistic transactions.
The essential problem with them lies in *IgniteTxAdapter#threadId*.
Thread id is se
The problem is that GridCacheTxFinishSync stores thread id. When we call
suspend on transaction, old thread id becames incorrect. So if this sync
class is useless, we can eliminate thread id storage and this class.
чт, 17 авг. 2017 г. в 15:47, ALEKSEY KUZNETSOV :
> I cannot find\create an example
I cannot find\create an example test scenario where a thread waits on it. A
thread can wait only if finish request had been sent and finish response
had not been received. But it seems, lock cannot proceed mapping in this
case. So, when lock call awaitFinishAckAsync, it is already done and thread
d
Aleksey,
GridCacheTxFinishSync is used in IgniteTxManager#awaitFinishAckAsync()
method (the wait is done before mapping Near or Colocated lock future, see
the call hierarchy).
--AG
2017-08-11 17:52 GMT+03:00 ALEKSEY KUZNETSOV :
> Hi!
> There is GridCacheTxFinishSync synchronizer, which used to
Hi!
There is GridCacheTxFinishSync synchronizer, which used to notify threads
(waiting on GridCacheTxFinishSync.TxFinishSync#pendingFut)
that GridNearTxFinishResponse is received.
Currently, only GridCacheTxFinishSync uses the synchronizer(but doesn't
wait on it somehow). And it seems the synchron
Hi, Igntrs!
Currently we have context switching implemented for optimistic transactions
: https://issues.apache.org/jira/browse/IGNITE-5712.
So, the next step is to implement it for pessimistic transactions :
https://issues.apache.org/jira/browse/IGNITE-5714
The problem with them lies in *Ig
Alexey Kuznetsov created IGNITE-5714:
Summary: Context switching for pessimistic transactions
Key: IGNITE-5714
URL: https://issues.apache.org/jira/browse/IGNITE-5714
Project: Ignite
Issue
