ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>
Subject Re: IGNITE-5714 Context switching for pessimistic transactions
Date Thu, 17 Aug 2017 12:47:44 GMT
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 <alexey.goncharuk@gmail.com>:

> 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 <alkuznetsov.sb@gmail.com>:
>
> > 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 <alkuznetsov.sb@gmail.com
> >:
> >
> > > 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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message