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