IGNITE-5714 Context switching for pessimistic transactions

[voipp]

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 *IgniteTxAdapter#threadId*. Thread id is
transferred between nodes by GridDistributedTxPrepareRequest when key is
got locked.

When we suspend and resume transaction, thread id is got changed locally,
but not on remote nodes.



After studying the code, it seemed we can eliminate thread id from
transactions completely.

For that reason, i want to start implementing additional tests, that will
cover transaction logic. Tickets would be created for them.
Later on I will provide test scenarious and send you. *Will appreciate any
ideas from you on new tests, thanks!*



It will be the first step. The next one will be refactoring and eliminating
thread id. What do you think ?

--

*Best Regards,*

*Kuznetsov Aleksey*

[voipp]

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 synchronizer is useless. Do we really
need to keep GridCacheTxFinishSync in a project?



ср, 9 авг. 2017 г. в 17:13, ALEKSEY KUZNETSOV <[hidden email]>:

> 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 *IgniteTxAdapter#threadId*. Thread id is
> transferred between nodes by GridDistributedTxPrepareRequest when key is
> got locked.
>
> When we suspend and resume transaction, thread id is got changed locally,
> but not on remote nodes.
>
>
>
> After studying the code, it seemed we can eliminate thread id from
> transactions completely.
>
> For that reason, i want to start implementing additional tests, that will
> cover transaction logic. Tickets would be created for them.
> Later on I will provide test scenarious and send you. *Will appreciate
> any ideas from you on new tests, thanks!*
>
>
>
> It will be the first step. The next one will be refactoring and
> eliminating thread id. What do you think ?
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[Alexey Goncharuk]

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 <[hidden email]>:

> 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 synchronizer is useless. Do we really
> need to keep GridCacheTxFinishSync in a project?
>
>
>
> ср, 9 авг. 2017 г. в 17:13, ALEKSEY KUZNETSOV <[hidden email]>:
>
> > 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 *IgniteTxAdapter#threadId*. Thread id is
> > transferred between nodes by GridDistributedTxPrepareRequest when key is
> > got locked.
> >
> > When we suspend and resume transaction, thread id is got changed locally,
> > but not on remote nodes.
> >
> >
> >
> > After studying the code, it seemed we can eliminate thread id from
> > transactions completely.
> >
> > For that reason, i want to start implementing additional tests, that will
> > cover transaction logic. Tickets would be created for them.
> > Later on I will provide test scenarious and send you. *Will appreciate
> > any ideas from you on new tests, thanks!*
> >
> >
> >
> > It will be the first step. The next one will be refactoring and
> > eliminating thread id. What do you think ?
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[voipp]

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
doesnt wait.

чт, 17 авг. 2017 г. в 14:17, Alexey Goncharuk <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 synchronizer is useless. Do we
> really
> > need to keep GridCacheTxFinishSync in a project?
> >
> >
> >
> > ср, 9 авг. 2017 г. в 17:13, ALEKSEY KUZNETSOV <[hidden email]
> >:
> >
> > > 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 *IgniteTxAdapter#threadId*. Thread id is
> > > transferred between nodes by GridDistributedTxPrepareRequest when key
> is
> > > got locked.
> > >
> > > When we suspend and resume transaction, thread id is got changed
> locally,
> > > but not on remote nodes.
> > >
> > >
> > >
> > > After studying the code, it seemed we can eliminate thread id from
> > > transactions completely.
> > >
> > > For that reason, i want to start implementing additional tests, that
> will
> > > cover transaction logic. Tickets would be created for them.
> > > Later on I will provide test scenarious and send you. *Will appreciate
> > > any ideas from you on new tests, thanks!*
> > >
> > >
> > >
> > > It will be the first step. The next one will be refactoring and
> > > eliminating thread id. What do you think ?
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>

--

*Best Regards,*

*Kuznetsov Aleksey*

[voipp]

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 <[hidden email]>:

> 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 doesnt wait.
>
> чт, 17 авг. 2017 г. в 14:17, Alexey Goncharuk <[hidden email]
> >:
>
>> 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 <[hidden email]>:
>>
>> > 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 synchronizer is useless. Do we
>> really
>> > need to keep GridCacheTxFinishSync in a project?
>> >
>> >
>> >
>> > ср, 9 авг. 2017 г. в 17:13, ALEKSEY KUZNETSOV <[hidden email]
>> >:
>> >
>> > > 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 *IgniteTxAdapter#threadId*. Thread id is
>> > > transferred between nodes by GridDistributedTxPrepareRequest when key
>> is
>> > > got locked.
>> > >
>> > > When we suspend and resume transaction, thread id is got changed
>> locally,
>> > > but not on remote nodes.
>> > >
>> > >
>> > >
>> > > After studying the code, it seemed we can eliminate thread id from
>> > > transactions completely.
>> > >
>> > > For that reason, i want to start implementing additional tests, that
>> will
>> > > cover transaction logic. Tickets would be created for them.
>> > > Later on I will provide test scenarious and send you. *Will appreciate
>> > > any ideas from you on new tests, thanks!*
>> > >
>> > >
>> > >
>> > > It will be the first step. The next one will be refactoring and
>> > > eliminating thread id. What do you think ?
>> > >
>> > > --
>> > >
>> > > *Best Regards,*
>> > >
>> > > *Kuznetsov Aleksey*
>> > >
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

--

*Best Regards,*

*Kuznetsov Aleksey*