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 <alkuznetsov...@gmail.com>: > 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.goncha...@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...@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...@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* > -- *Best Regards,* *Kuznetsov Aleksey*
