Re: IGNITE-5714 Context switching for pessimistic transactions

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

Re: IGNITE-5714 Context switching for pessimistic transactions

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,

IGNITE-5714 Context switching for pessimistic transactions

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

Re: Context switching for pessimistic transactions

Hi, Igntrs! I have implemented context switching for pessimistic transactions. The main idea is to get rid of sending transaction thread id to other nodes. So when switching context you only need to change thread id locally. Please, review. [1] *https://issues.apache.org/jira/browse/IGNITE-5714

Re: Context switching for pessimistic transactions

Hi, Igntrs! I’m working on a ticket "Context switching for pessimistic transactions" [1]. Goal of the ticket is to support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. Imagine, we started a pessimistic transaction in

Re: Context switching for pessimistic transactions

Hi, Igntrs! I would like to implement suspend\resume methods of a pessimistic transaction as following: if transaction holds lock on a key and suspend method has been called no keys would be unlocked. Therefore, if transaction holds lock on a key and suspend method has been called, topology

Re: Context switching for pessimistic transactions

On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV wrote: > Hi, Igntrs! > > For suspend\resume operations in pessimistic mode we want to write the same > tests as for optimistic mode. > > What additional tests should we create for the task? Alexey, I think you should

Re: Context switching for pessimistic transactions

2, 2017 at 3:49 PM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > wrote: > > > Hi, Igntrs! > > > > I’m working on a ticket "Context switching for pessimistic transactions" > > [1]. > > > > Goal of the ticket is to support t

Re: Context switching for pessimistic transactions

<alkuznetsov...@gmail.com> wrote: > Hi, Igntrs! > > I’m working on a ticket "Context switching for pessimistic transactions" > [1]. > > Goal of the ticket is to support transaction suspend()\resume() operations > for pessimistic transactions. Resume can be call

Context switching for pessimistic transactions

Hi, Igntrs! I’m working on a ticket "Context switching for pessimistic transactions" [1]. Goal of the ticket is to support transaction suspend()\resume() operations for pessimistic transactions. Resume can be called in another thread. Imagine, we started pessimistic transaction in

Re: IGNITE-5714 Context switching for pessimistic transactions

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

Re: IGNITE-5714 Context switching for pessimistic transactions

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

Re: IGNITE-5714 Context switching for pessimistic transactions

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

Re: IGNITE-5714 Context switching for pessimistic transactions

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

IGNITE-5714 Context switching for pessimistic transactions

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

[jira] [Created] (IGNITE-5714) Context switching for pessimistic transactions

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