Re: IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

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,
but not on remote nodes.

Actually, we don't need local tx thread id on remote nodes.

This brings us to the solution. Remove thread id from prepare\finish
requests\responses and don't use it remotely.
But preserve it in lock requests, so long as cache lock uses thread id on
remote nodes. Such changes let us not send thread id to remote nodes,
and eliminate the core problem.
Thread id is moved from global IgniteTxAdapter to GridNearTxLocal, as long
as only *near local* transaction is need it.
Now, only candidates, created by near tx local have got thread id
defined.(i.e. remote candidates have got thread id undefined)
Thread id in GridCacheTxFinishSync is replaced with version check(so we
don't need to store and send thread id along with finish response).
When pessimistic tx is resumed, then candidates are updated with new thread
id.
Lock check in IgniteTxAdapter#ownsLock now is done against version(not
thread id, because version is unique).

2) No new messages needed for near lock requests, because thread id is
preserved for cache lock requests.
We still need to replace thread id with version check in TxFinishSync in
other solution.
In other solution we need to change cache lock code : replace thread id
with new tx counter.
In another solution we still need to remove thread id from
requests\responses.

If my design is OK I will do benchmarking

вт, 13 февр. 2018 г. в 18:22, Nikolay Izhikov :

> 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!
> >
> >  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 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,
> > but not on remote nodes.
> >
> >  In ticket I decided to partly remove thread id from source, and
> introduced
> > *undefined* value for it, where its value must be ignored.
> >  Another solution can be to replace thread id usage with some new global
> > transaction id counter.
> >
> >  The former solution has advantages :
> >  compatibility is preserved, step-by-step clear implementation, minimal
> > changes to explicit cache lock work(it still creates candidates with
> > not-null thread id) as opposed to the last solution.
> >
> >  There are 3 possible solutions to "thread id on remote nodes" issue :
> >  1) Change thread id on remote nodes once suspend()\resume() is called.
> >  2) Get rid of sending thread id to remote nodes.
> >  3) Don’t remove the field, just put -1 (undefined) in it.
> >
> >  The last option was chosen, because it will save compatibility in
> cluster
> > with nodes of older versions.
> >  Note that still outside the transaction, when explicit cache lock is
> > created, thread id is set not null value in lock request(i.e.
> > GridNearLockRequest).
> >
> >  Thread id is moved from global IgniteTxAdapter to GridNearTxLocal, as
> long
> > as only *near local* transaction is need it.
> >  For instance, when local candidate(either near local or dht local) is
> > created for GridNearTxLocal. Note that remote candidates are created with
> > thread id undefined, because it useless for non-local candidates.
> >  In IgniteTxAdapter#ownsLock thread id is replaced with tx version check.
> >  We could do it, because near transactions has got unique versions to
> check
> > against.
> >
> >  In tx synchronizer GridCacheTxFinishSync thread id is replaced with tx
> > version, so we don't need to store it and send by GridFinishResponse
> > messages.
> >  As a consequence, thread id is also removed from grid near
> finish\prepare
> > request\response.
> >
> >  Also, thread id information is removed from deadlock messages (in
> > TxDeadlock, TxDeadlockDetection).
> >
> > Please, review it:
> >
> > ticket *https://issues.apache.org/jira/browse/IGNITE-5714
> > *
> > pull request *https://github.com/apache/ignite/pull/2789
> > *
> > review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-364
> >
> >  [1] : 

Re: IGNITE-5714 Context switching for pessimistic transactions

[Nikolay Izhikov]

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!
> 
>  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 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,
> but not on remote nodes.
> 
>  In ticket I decided to partly remove thread id from source, and introduced
> *undefined* value for it, where its value must be ignored.
>  Another solution can be to replace thread id usage with some new global
> transaction id counter.
> 
>  The former solution has advantages :
>  compatibility is preserved, step-by-step clear implementation, minimal
> changes to explicit cache lock work(it still creates candidates with
> not-null thread id) as opposed to the last solution.
> 
>  There are 3 possible solutions to "thread id on remote nodes" issue :
>  1) Change thread id on remote nodes once suspend()\resume() is called.
>  2) Get rid of sending thread id to remote nodes.
>  3) Don’t remove the field, just put -1 (undefined) in it.
> 
>  The last option was chosen, because it will save compatibility in cluster
> with nodes of older versions.
>  Note that still outside the transaction, when explicit cache lock is
> created, thread id is set not null value in lock request(i.e.
> GridNearLockRequest).
> 
>  Thread id is moved from global IgniteTxAdapter to GridNearTxLocal, as long
> as only *near local* transaction is need it.
>  For instance, when local candidate(either near local or dht local) is
> created for GridNearTxLocal. Note that remote candidates are created with
> thread id undefined, because it useless for non-local candidates.
>  In IgniteTxAdapter#ownsLock thread id is replaced with tx version check.
>  We could do it, because near transactions has got unique versions to check
> against.
> 
>  In tx synchronizer GridCacheTxFinishSync thread id is replaced with tx
> version, so we don't need to store it and send by GridFinishResponse
> messages.
>  As a consequence, thread id is also removed from grid near finish\prepare
> request\response.
> 
>  Also, thread id information is removed from deadlock messages (in
> TxDeadlock, TxDeadlockDetection).
> 
> Please, review it:
> 
> ticket *https://issues.apache.org/jira/browse/IGNITE-5714
> *
> pull request *https://github.com/apache/ignite/pull/2789
> *
> review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-364
> 
>  [1] : https://issues.apache.org/jira/browse/IGNITE-5712.

signature.asc
Description: This is a digitally signed message part

IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

 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 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,
but not on remote nodes.

 In ticket I decided to partly remove thread id from source, and introduced
*undefined* value for it, where its value must be ignored.
 Another solution can be to replace thread id usage with some new global
transaction id counter.

 The former solution has advantages :
 compatibility is preserved, step-by-step clear implementation, minimal
changes to explicit cache lock work(it still creates candidates with
not-null thread id) as opposed to the last solution.

 There are 3 possible solutions to "thread id on remote nodes" issue :
 1) Change thread id on remote nodes once suspend()\resume() is called.
 2) Get rid of sending thread id to remote nodes.
 3) Don’t remove the field, just put -1 (undefined) in it.

 The last option was chosen, because it will save compatibility in cluster
with nodes of older versions.
 Note that still outside the transaction, when explicit cache lock is
created, thread id is set not null value in lock request(i.e.
GridNearLockRequest).

 Thread id is moved from global IgniteTxAdapter to GridNearTxLocal, as long
as only *near local* transaction is need it.
 For instance, when local candidate(either near local or dht local) is
created for GridNearTxLocal. Note that remote candidates are created with
thread id undefined, because it useless for non-local candidates.
 In IgniteTxAdapter#ownsLock thread id is replaced with tx version check.
 We could do it, because near transactions has got unique versions to check
against.

 In tx synchronizer GridCacheTxFinishSync thread id is replaced with tx
version, so we don't need to store it and send by GridFinishResponse
messages.
 As a consequence, thread id is also removed from grid near finish\prepare
request\response.

 Also, thread id information is removed from deadlock messages (in
TxDeadlock, TxDeadlockDetection).

Please, review it:

ticket *https://issues.apache.org/jira/browse/IGNITE-5714
*
pull request *https://github.com/apache/ignite/pull/2789
*
review https://reviews.ignite.apache.org/ignite/review/IGNT-CR-364

 [1] : https://issues.apache.org/jira/browse/IGNITE-5712.
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

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 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  >:
>
>> 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 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 > >:
>> >
>> > > 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*

Re: IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

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 :

> 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 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  >:
> >
> > > 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*

Re: IGNITE-5714 Context switching for pessimistic transactions

[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 :

> 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 :
>
> > 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*
>

Re: IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

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 :

> 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*

IGNITE-5714 Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

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*

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

[Alexey Kuznetsov (JIRA)]

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 Type: Sub-task
Reporter: Alexey Kuznetsov


Implement context switching for pessimistic transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)