Aleksey, I doubt your approach works as expected. Current transaction recovery protocol heavily relies on the originating node ID in its internal logic. For example, currently a transaction will be rolled back if you want to transfer a transaction ownership to another node and original tx owner fails. An attempt to commit such a transaction on another node may fail with all sorts of assertions. After transaction ownership changed, you need to notify all current transaction participants about this change, and it should also be done failover-safe, let alone that you did not add any tests for these cases.
I back Denis here. Please create a ticket first and come up with clear use-cases, API and protocol changes design. It is hard to reason about the changes you've made when we do not even understand why you are making these changes and how they are supposed to work. --AG 2017-03-30 10:43 GMT+03:00 ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > So, what do u think on my idea ? > > ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com>: > > > Hi! No, i dont have ticket for this. > > In the ticket i have implemented methods that change transaction status > to > > STOP, thus letting it to commit transaction in another thread. In another > > thread you r going to restart transaction in order to commit it. > > The mechanism behind it is obvious : we change thread id to newer one in > > ThreadMap, and make use of serialization of txState, transactions itself > to > > transfer them into another thread. > > > > > > вт, 28 мар. 2017 г. в 20:15, Denis Magda <dma...@apache.org>: > > > > Aleksey, > > > > Do you have a ticket for this? Could you briefly list what exactly was > > done and how the things work. > > > > — > > Denis > > > > > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com> > > wrote: > > > > > > Hi, Igniters! I 've made implementation of transactions of non-single > > > coordinator. Here you can start transaction in one thread and commit it > > in > > > another thread. > > > Take a look on it. Give your thoughts on it. > > > > > > > > https://github.com/voipp/ignite/pull/10/commits/ > 3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45 > > > > > > пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin <sergi.vlady...@gmail.com > >: > > > > > >> You know better, go ahead! :) > > >> > > >> Sergi > > >> > > >> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV < > alkuznetsov...@gmail.com > > >: > > >> > > >>> we've discovered several problems regarding your "accumulation" > > >>> approach.These are > > >>> > > >>> 1. perfomance issues when transfering data from temporary cache to > > >>> permanent one. Keep in mind big deal of concurent transactions in > > >>> Service > > >>> commiter > > >>> 2. extreme memory load when keeping temporary cache in memory > > >>> 3. As long as user is not acquainted with ignite, working with > cache > > >>> must be transparent for him. Keep this in mind. User's node can > > >> evaluate > > >>> logic with no transaction at all, so we should deal with both types > > of > > >>> execution flow : transactional and non-transactional.Another one > > >>> problem is > > >>> transaction id support at the user node. We would have handled all > > >> this > > >>> issues and many more. > > >>> 4. we cannot pessimistically lock entity. > > >>> > > >>> As a result, we decided to move on building distributed transaction. > We > > >> put > > >>> aside your "accumulation" approach until we realize how to solve > > >>> difficulties above . > > >>> > > >>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin < > sergi.vlady...@gmail.com > > >: > > >>> > > >>>> The problem "How to run millions of entities, and millions of > > >> operations > > >>> on > > >>>> a single Pentium3" is out of scope here. Do the math, plan capacity > > >>>> reasonably. > > >>>> > > >>>> Sergi > > >>>> > > >>>> 2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV < > > alkuznetsov...@gmail.com > > >>> : > > >>>> > > >>>>> hmm, If we have millions of entities, and millions of operations, > > >> would > > >>>> not > > >>>>> this approache lead to memory overflow and perfomance degradation > > >>>>> > > >>>>> чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin < > > >> sergi.vlady...@gmail.com > > >>>> : > > >>>>> > > >>>>>> 1. Actually you have to check versions on all the values you have > > >>> read > > >>>>>> during the tx. > > >>>>>> > > >>>>>> For example if we have [k1 => v1, k2 => v2] and do: > > >>>>>> > > >>>>>> put(k1, get(k2) + 5) > > >>>>>> > > >>>>>> We have to remember the version for k2. This logic can be > > >> relatively > > >>>>> easily > > >>>>>> encapsulated in a framework atop of Ignite. You need to implement > > >> one > > >>>> to > > >>>>>> make all this stuff usable. > > >>>>>> > > >>>>>> 2. I suggest to avoid any locking here, because you easily will > end > > >>> up > > >>>>> with > > >>>>>> deadlocks. If you do not have too frequent updates for your keys, > > >>>>>> optimistic approach will work just fine. > > >>>>>> > > >>>>>> Theoretically in the Committer Service you can start a thread for > > >> the > > >>>>>> lifetime of the whole distributed transaction, take a lock on the > > >> key > > >>>>> using > > >>>>>> IgniteCache.lock(K key) before executing any Services, wait for > all > > >>> the > > >>>>>> services to complete, execute optimistic commit in the same thread > > >>>> while > > >>>>>> keeping this lock and then release it. Notice that all the Ignite > > >>>>>> transactions inside of all Services must be optimistic here to be > > >>> able > > >>>> to > > >>>>>> read this locked key. > > >>>>>> > > >>>>>> But again I do not recommend you using this approach until you > > >> have a > > >>>>>> reliable deadlock avoidance scheme. > > >>>>>> > > >>>>>> Sergi > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV < > > >>> alkuznetsov...@gmail.com > > >>>>> : > > >>>>>> > > >>>>>>> Yeah, now i got it. > > >>>>>>> There are some doubts on this approach > > >>>>>>> 1) During optimistic commit phase, when you assure no one altered > > >>> the > > >>>>>>> original values, you must check versions of other dependent keys. > > >>> How > > >>>>>> could > > >>>>>>> we obtain those keys(in an automative manner, of course) ? > > >>>>>>> 2) How could we lock a key before some Service A introduce > > >> changes? > > >>>> So > > >>>>> no > > >>>>>>> other service is allowed to change this key-value?(sort of > > >>>> pessimistic > > >>>>>>> blocking) > > >>>>>>> May be you know some implementations of such approach ? > > >>>>>>> > > >>>>>>> ср, 15 мар. 2017 г. в 17:54, ALEKSEY KUZNETSOV < > > >>>>> alkuznetsov...@gmail.com > > >>>>>>> : > > >>>>>>> > > >>>>>>>> Thank you very much for help. I will answer later. > > >>>>>>>> > > >>>>>>>> ср, 15 мар. 2017 г. в 17:39, Sergi Vladykin < > > >>>>> sergi.vlady...@gmail.com > > >>>>>>> : > > >>>>>>>> > > >>>>>>>> All the services do not update key in place, but only generate > > >>> new > > >>>>> keys > > >>>>>>>> augmented by otx and store the updated value in the same cache > > >> + > > >>>>>> remember > > >>>>>>>> the keys and versions participating in the transaction in some > > >>>>> separate > > >>>>>>>> atomic cache. > > >>>>>>>> > > >>>>>>>> Follow this sequence of changes applied to cache contents by > > >> each > > >>>>>>> Service: > > >>>>>>>> > > >>>>>>>> Initial cache contents: > > >>>>>>>> [k1 => v1] > > >>>>>>>> [k2 => v2] > > >>>>>>>> [k3 => v3] > > >>>>>>>> > > >>>>>>>> Cache contents after Service A: > > >>>>>>>> [k1 => v1] > > >>>>>>>> [k2 => v2] > > >>>>>>>> [k3 => v3] > > >>>>>>>> [k1x => v1a] > > >>>>>>>> [k2x => v2a] > > >>>>>>>> > > >>>>>>>> + [x => (k1 -> ver1, k2 -> ver2)] in some separate > > >>> atomic > > >>>>>> cache > > >>>>>>>> > > >>>>>>>> Cache contents after Service B: > > >>>>>>>> [k1 => v1] > > >>>>>>>> [k2 => v2] > > >>>>>>>> [k3 => v3] > > >>>>>>>> [k1x => v1a] > > >>>>>>>> [k2x => v2ab] > > >>>>>>>> [k3x => v3b] > > >>>>>>>> > > >>>>>>>> + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some > > >>>>> separate > > >>>>>>>> atomic cache > > >>>>>>>> > > >>>>>>>> Finally the Committer Service takes this map of updated keys > > >> and > > >>>>> their > > >>>>>>>> versions from some separate atomic cache, starts Ignite > > >>> transaction > > >>>>> and > > >>>>>>>> replaces all the values for k* keys to values taken from k*x > > >>> keys. > > >>>>> The > > >>>>>>>> successful result must be the following: > > >>>>>>>> > > >>>>>>>> [k1 => v1a] > > >>>>>>>> [k2 => v2ab] > > >>>>>>>> [k3 => v3b] > > >>>>>>>> [k1x => v1a] > > >>>>>>>> [k2x => v2ab] > > >>>>>>>> [k3x => v3b] > > >>>>>>>> > > >>>>>>>> + [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] in some > > >>>>> separate > > >>>>>>>> atomic cache > > >>>>>>>> > > >>>>>>>> But Committer Service also has to check that no one updated the > > >>>>>> original > > >>>>>>>> values before us, because otherwise we can not give any > > >>>>> serializability > > >>>>>>>> guarantee for these distributed transactions. Here we may need > > >> to > > >>>>> check > > >>>>>>> not > > >>>>>>>> only versions of the updated keys, but also versions of any > > >> other > > >>>>> keys > > >>>>>>> end > > >>>>>>>> result depends on. > > >>>>>>>> > > >>>>>>>> After that Committer Service has to do a cleanup (may be > > >> outside > > >>> of > > >>>>> the > > >>>>>>>> committing tx) to come to the following final state: > > >>>>>>>> > > >>>>>>>> [k1 => v1a] > > >>>>>>>> [k2 => v2ab] > > >>>>>>>> [k3 => v3b] > > >>>>>>>> > > >>>>>>>> Makes sense? > > >>>>>>>> > > >>>>>>>> Sergi > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> 2017-03-15 16:54 GMT+03:00 ALEKSEY KUZNETSOV < > > >>>>> alkuznetsov...@gmail.com > > >>>>>>> : > > >>>>>>>> > > >>>>>>>>> - what do u mean by saying " > > >>>>>>>>> *in a single transaction checks value versions for all the > > >> old > > >>>>> values > > >>>>>>>>> and replaces them with calculated new ones *"? Every time > > >>> you > > >>>>>>> change > > >>>>>>>>> value(in some service), you store it to *some special > > >> atomic > > >>>>>> cache* > > >>>>>>> , > > >>>>>>>> so > > >>>>>>>>> when all services ceased working, Service commiter got a > > >>>> values > > >>>>>> with > > >>>>>>>> the > > >>>>>>>>> last versions. > > >>>>>>>>> - After "*does cleanup of temporary keys and values*" > > >>> Service > > >>>>>>> commiter > > >>>>>>>>> persists them into permanent store, isn't it ? > > >>>>>>>>> - I cant grasp your though, you say "*in case of version > > >>>>> mismatch > > >>>>>> or > > >>>>>>>> TX > > >>>>>>>>> timeout just rollbacks*". But what versions would it > > >> match? > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> ср, 15 мар. 2017 г. в 15:34, Sergi Vladykin < > > >>>>>> sergi.vlady...@gmail.com > > >>>>>>>> : > > >>>>>>>>> > > >>>>>>>>>> Ok, here is what you actually need to implement at the > > >>>>> application > > >>>>>>>> level. > > >>>>>>>>>> > > >>>>>>>>>> Lets say we have to call 2 services in the following order: > > >>>>>>>>>> - Service A: wants to update keys [k1 => v1, k2 => v2] > > >> to > > >>>>> [k1 > > >>>>>> => > > >>>>>>>>> v1a, > > >>>>>>>>>> k2 => v2a] > > >>>>>>>>>> - Service B: wants to update keys [k2 => v2a, k3 => v3] > > >> to > > >>>> [k2 > > >>>>>> => > > >>>>>>>>> v2ab, > > >>>>>>>>>> k3 => v3b] > > >>>>>>>>>> > > >>>>>>>>>> The change > > >>>>>>>>>> from [ k1 => v1, k2 => v2, k3 => v3 ] > > >>>>>>>>>> to [ k1 => v1a, k2 => v2ab, k3 => v3b ] > > >>>>>>>>>> must happen in a single transaction. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Optimistic protocol to solve this: > > >>>>>>>>>> > > >>>>>>>>>> Each cache key must have a field `otx`, which is a unique > > >>>>>>> orchestrator > > >>>>>>>> TX > > >>>>>>>>>> identifier - it must be a parameter passed to all the > > >>> services. > > >>>>> If > > >>>>>>>> `otx` > > >>>>>>>>> is > > >>>>>>>>>> set to some value it means that it is an intermediate key > > >> and > > >>>> is > > >>>>>>>> visible > > >>>>>>>>>> only inside of some transaction, for the finalized key > > >> `otx` > > >>>> must > > >>>>>> be > > >>>>>>>>> null - > > >>>>>>>>>> it means the key is committed and visible for everyone. > > >>>>>>>>>> > > >>>>>>>>>> Each cache value must have a field `ver` which is a version > > >>> of > > >>>>> that > > >>>>>>>>> value. > > >>>>>>>>>> > > >>>>>>>>>> For both fields (`otx` and `ver`) the safest way is to use > > >>>> UUID. > > >>>>>>>>>> > > >>>>>>>>>> Workflow is the following: > > >>>>>>>>>> > > >>>>>>>>>> Orchestrator starts the distributed transaction with `otx` > > >> = > > >>> x > > >>>>> and > > >>>>>>>> passes > > >>>>>>>>>> this parameter to all the services. > > >>>>>>>>>> > > >>>>>>>>>> Service A: > > >>>>>>>>>> - does some computations > > >>>>>>>>>> - stores [k1x => v1a, k2x => v2a] with TTL = Za > > >>>>>>>>>> where > > >>>>>>>>>> Za - left time from max Orchestrator TX duration > > >>>> after > > >>>>>>>> Service > > >>>>>>>>> A > > >>>>>>>>>> end > > >>>>>>>>>> k1x, k2x - new temporary keys with field `otx` = > > >> x > > >>>>>>>>>> v2a has updated version `ver` > > >>>>>>>>>> - returns a set of updated keys and all the old versions > > >> to > > >>>> the > > >>>>>>>>>> orchestrator > > >>>>>>>>>> or just stores it in some special atomic cache like > > >>>>>>>>>> [x => (k1 -> ver1, k2 -> ver2)] TTL = Za > > >>>>>>>>>> > > >>>>>>>>>> Service B: > > >>>>>>>>>> - retrieves the updated value k2x => v2a because it knows > > >>>> `otx` > > >>>>> = > > >>>>>> x > > >>>>>>>>>> - does computations > > >>>>>>>>>> - stores [k2x => v2ab, k3x => v3b] TTL = Zb > > >>>>>>>>>> - updates the set of updated keys like [x => (k1 -> ver1, > > >> k2 > > >>>> -> > > >>>>>>> ver2, > > >>>>>>>> k3 > > >>>>>>>>>> -> ver3)] TTL = Zb > > >>>>>>>>>> > > >>>>>>>>>> Service Committer (may be embedded into Orchestrator): > > >>>>>>>>>> - takes all the updated keys and versions for `otx` = x > > >>>>>>>>>> [x => (k1 -> ver1, k2 -> ver2, k3 -> ver3)] > > >>>>>>>>>> - in a single transaction checks value versions for all > > >> the > > >>>> old > > >>>>>>> values > > >>>>>>>>>> and replaces them with calculated new ones > > >>>>>>>>>> - does cleanup of temporary keys and values > > >>>>>>>>>> - in case of version mismatch or TX timeout just rollbacks > > >>> and > > >>>>>>> signals > > >>>>>>>>>> to Orchestrator to restart the job with new `otx` > > >>>>>>>>>> > > >>>>>>>>>> PROFIT!! > > >>>>>>>>>> > > >>>>>>>>>> This approach even allows you to run independent parts of > > >> the > > >>>>> graph > > >>>>>>> in > > >>>>>>>>>> parallel (with TX transfer you will always run only one at > > >> a > > >>>>> time). > > >>>>>>>> Also > > >>>>>>>>> it > > >>>>>>>>>> does not require inventing any special fault tolerance > > >>> technics > > >>>>>>> because > > >>>>>>>>>> Ignite caches are already fault tolerant and all the > > >>>> intermediate > > >>>>>>>> results > > >>>>>>>>>> are virtually invisible and stored with TTL, thus in case > > >> of > > >>>> any > > >>>>>>> crash > > >>>>>>>>> you > > >>>>>>>>>> will not have inconsistent state or garbage. > > >>>>>>>>>> > > >>>>>>>>>> Sergi > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> 2017-03-15 11:42 GMT+03:00 ALEKSEY KUZNETSOV < > > >>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>> : > > >>>>>>>>>> > > >>>>>>>>>>> Okay, we are open for proposals on business task. I mean, > > >>> we > > >>>>> can > > >>>>>>> make > > >>>>>>>>> use > > >>>>>>>>>>> of some other thing, not distributed transaction. Not > > >>>>> transaction > > >>>>>>>> yet. > > >>>>>>>>>>> > > >>>>>>>>>>> ср, 15 мар. 2017 г. в 11:24, Vladimir Ozerov < > > >>>>>> voze...@gridgain.com > > >>>>>>>> : > > >>>>>>>>>>> > > >>>>>>>>>>>> IMO the use case makes sense. However, as Sergi already > > >>>>>>> mentioned, > > >>>>>>>>> the > > >>>>>>>>>>>> problem is far more complex, than simply passing TX > > >> state > > >>>>> over > > >>>>>> a > > >>>>>>>>> wire. > > >>>>>>>>>>> Most > > >>>>>>>>>>>> probably a kind of coordinator will be required still > > >> to > > >>>>> manage > > >>>>>>> all > > >>>>>>>>>> kinds > > >>>>>>>>>>>> of failures. This task should be started with clean > > >>> design > > >>>>>>> proposal > > >>>>>>>>>>>> explaining how we handle all these concurrent events. > > >> And > > >>>>> only > > >>>>>>>> then, > > >>>>>>>>>> when > > >>>>>>>>>>>> we understand all implications, we should move to > > >>>> development > > >>>>>>>> stage. > > >>>>>>>>>>>> > > >>>>>>>>>>>> On Wed, Mar 15, 2017 at 10:38 AM, ALEKSEY KUZNETSOV < > > >>>>>>>>>>>> alkuznetsov...@gmail.com> wrote: > > >>>>>>>>>>>> > > >>>>>>>>>>>>> Right > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> ср, 15 мар. 2017 г. в 10:35, Sergi Vladykin < > > >>>>>>>>>> sergi.vlady...@gmail.com > > >>>>>>>>>>>> : > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> Good! Basically your orchestrator just takes some > > >>>>>> predefined > > >>>>>>>>> graph > > >>>>>>>>>> of > > >>>>>>>>>>>>>> distributed services to be invoked, calls them by > > >>> some > > >>>>> kind > > >>>>>>> of > > >>>>>>>>> RPC > > >>>>>>>>>>> and > > >>>>>>>>>>>>>> passes the needed parameters between them, right? > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Sergi > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> 2017-03-14 22:46 GMT+03:00 ALEKSEY KUZNETSOV < > > >>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>> : > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> orchestrator is a custom thing. He is responsible > > >>> for > > >>>>>>>> managing > > >>>>>>>>>>>> business > > >>>>>>>>>>>>>>> scenarios flows. Many nodes are involved in > > >>>> scenarios. > > >>>>>> They > > >>>>>>>>>>> exchange > > >>>>>>>>>>>>> data > > >>>>>>>>>>>>>>> and folow one another. If you acquinted with BPMN > > >>>>>>> framework, > > >>>>>>>> so > > >>>>>>>>>>>>>>> orchestrator is like bpmn engine. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> вт, 14 Мар 2017 г., 18:56 Sergi Vladykin < > > >>>>>>>>>> sergi.vlady...@gmail.com > > >>>>>>>>>>>> : > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> What is Orchestrator for you? Is it a thing > > >> from > > >>>>>>> Microsoft > > >>>>>>>> or > > >>>>>>>>>>> your > > >>>>>>>>>>>>>> custom > > >>>>>>>>>>>>>>>> in-house software? > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Sergi > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> 2017-03-14 18:00 GMT+03:00 ALEKSEY KUZNETSOV < > > >>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Fine. Let's say we've got multiple servers > > >>> which > > >>>>>>> fulfills > > >>>>>>>>>>> custom > > >>>>>>>>>>>>>> logic. > > >>>>>>>>>>>>>>>>> This servers compound oriented graph (BPMN > > >>>> process) > > >>>>>>> which > > >>>>>>>>>>>>> controlled > > >>>>>>>>>>>>>> by > > >>>>>>>>>>>>>>>>> Orchestrator. > > >>>>>>>>>>>>>>>>> For instance, *server1 *creates *variable A > > >>>> *with > > >>>>>>> value > > >>>>>>>> 1, > > >>>>>>>>>>>>> persists > > >>>>>>>>>>>>>> it > > >>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>> IGNITE cache and creates *variable B *and > > >> sends > > >>>> it > > >>>>>> to* > > >>>>>>>>>> server2. > > >>>>>>>>>>>>> *The > > >>>>>>>>>>>>>>>>> latests receives *variable B*, do some logic > > >>> with > > >>>>> it > > >>>>>>> and > > >>>>>>>>>> stores > > >>>>>>>>>>>> to > > >>>>>>>>>>>>>>>> IGNITE. > > >>>>>>>>>>>>>>>>> All the work made by both servers must be > > >>>> fulfilled > > >>>>>> in > > >>>>>>>>> *one* > > >>>>>>>>>>>>>>> transaction. > > >>>>>>>>>>>>>>>>> Because we need all information done, or > > >>>>>>>>> nothing(rollbacked). > > >>>>>>>>>>> The > > >>>>>>>>>>>>>>>> scenario > > >>>>>>>>>>>>>>>>> is managed by orchestrator. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> вт, 14 мар. 2017 г. в 17:31, Sergi Vladykin < > > >>>>>>>>>>>>>> sergi.vlady...@gmail.com > > >>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Ok, it is not a business case, it is your > > >>> wrong > > >>>>>>>> solution > > >>>>>>>>>> for > > >>>>>>>>>>>> it. > > >>>>>>>>>>>>>>>>>> Lets try again, what is the business case? > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Sergi > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> 2017-03-14 16:42 GMT+03:00 ALEKSEY > > >> KUZNETSOV > > >>> < > > >>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> The case is the following, One starts > > >>>>> transaction > > >>>>>>> in > > >>>>>>>>> one > > >>>>>>>>>>>> node, > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>> commit > > >>>>>>>>>>>>>>>>>>> this transaction in another jvm node(or > > >>>>> rollback > > >>>>>> it > > >>>>>>>>>>>> remotely). > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> вт, 14 мар. 2017 г. в 16:30, Sergi > > >>> Vladykin < > > >>>>>>>>>>>>>>>> sergi.vlady...@gmail.com > > >>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Because even if you make it work for > > >> some > > >>>>>>>> simplistic > > >>>>>>>>>>>>> scenario, > > >>>>>>>>>>>>>>> get > > >>>>>>>>>>>>>>>>>> ready > > >>>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>> write many fault tolerance tests and > > >> make > > >>>>> sure > > >>>>>>> that > > >>>>>>>>> you > > >>>>>>>>>>> TXs > > >>>>>>>>>>>>>> work > > >>>>>>>>>>>>>>>>>>> gracefully > > >>>>>>>>>>>>>>>>>>>> in all modes in case of crashes. Also > > >>> make > > >>>>> sure > > >>>>>>>> that > > >>>>>>>>> we > > >>>>>>>>>>> do > > >>>>>>>>>>>>> not > > >>>>>>>>>>>>>>> have > > >>>>>>>>>>>>>>>>> any > > >>>>>>>>>>>>>>>>>>>> performance drops after all your > > >> changes > > >>> in > > >>>>>>>> existing > > >>>>>>>>>>>>>> benchmarks. > > >>>>>>>>>>>>>>>> All > > >>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>> all > > >>>>>>>>>>>>>>>>>>>> I don't believe these conditions will > > >> be > > >>>> met > > >>>>>> and > > >>>>>>>> your > > >>>>>>>>>>>>>>> contribution > > >>>>>>>>>>>>>>>>> will > > >>>>>>>>>>>>>>>>>>> be > > >>>>>>>>>>>>>>>>>>>> accepted. > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Better solution to what problem? > > >> Sending > > >>> TX > > >>>>> to > > >>>>>>>>> another > > >>>>>>>>>>>> node? > > >>>>>>>>>>>>>> The > > >>>>>>>>>>>>>>>>>> problem > > >>>>>>>>>>>>>>>>>>>> statement itself is already wrong. What > > >>>>>> business > > >>>>>>>> case > > >>>>>>>>>> you > > >>>>>>>>>>>> are > > >>>>>>>>>>>>>>>> trying > > >>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>> solve? I'm sure everything you need can > > >>> be > > >>>>> done > > >>>>>>> in > > >>>>>>>> a > > >>>>>>>>>> much > > >>>>>>>>>>>>> more > > >>>>>>>>>>>>>>>> simple > > >>>>>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>>> efficient way at the application level. > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Sergi > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> 2017-03-14 16:03 GMT+03:00 ALEKSEY > > >>>> KUZNETSOV > > >>>>> < > > >>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Why wrong ? You know the better > > >>> solution? > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> вт, 14 мар. 2017 г. в 15:46, Sergi > > >>>>> Vladykin < > > >>>>>>>>>>>>>>>>>> sergi.vlady...@gmail.com > > >>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Just serializing TX object and > > >>>>>> deserializing > > >>>>>>> it > > >>>>>>>>> on > > >>>>>>>>>>>>> another > > >>>>>>>>>>>>>>> node > > >>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>>>> meaningless, because other nodes > > >>>>>>> participating > > >>>>>>>> in > > >>>>>>>>>> the > > >>>>>>>>>>>> TX > > >>>>>>>>>>>>>> have > > >>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>> know > > >>>>>>>>>>>>>>>>>>>>> about > > >>>>>>>>>>>>>>>>>>>>>> the new coordinator. This will > > >>> require > > >>>>>>> protocol > > >>>>>>>>>>>> changes, > > >>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>>> definitely > > >>>>>>>>>>>>>>>>>>>>> will > > >>>>>>>>>>>>>>>>>>>>>> have fault tolerance and > > >> performance > > >>>>>> issues. > > >>>>>>>> IMO > > >>>>>>>>>> the > > >>>>>>>>>>>>> whole > > >>>>>>>>>>>>>>> idea > > >>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>> wrong > > >>>>>>>>>>>>>>>>>>>>>> and it makes no sense to waste time > > >>> on > > >>>>> it. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Sergi > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> 2017-03-14 10:57 GMT+03:00 ALEKSEY > > >>>>>> KUZNETSOV > > >>>>>>> < > > >>>>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> IgniteTransactionState > > >>>> implememntation > > >>>>>>>> contains > > >>>>>>>>>>>>>>>> IgniteTxEntry's > > >>>>>>>>>>>>>>>>>>> which > > >>>>>>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>>>>> supposed to be transferable > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>> пн, 13 мар. 2017 г. в 19:32, > > >>> Dmitriy > > >>>>>>>> Setrakyan > > >>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>> dsetrak...@apache.org > > >>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> It sounds a little scary to me > > >>> that > > >>>>> we > > >>>>>>> are > > >>>>>>>>>>> passing > > >>>>>>>>>>>>>>>>> transaction > > >>>>>>>>>>>>>>>>>>>>> objects > > >>>>>>>>>>>>>>>>>>>>>>>> around. Such object may contain > > >>> all > > >>>>>> sorts > > >>>>>>>> of > > >>>>>>>>>>> Ignite > > >>>>>>>>>>>>>>>> context. > > >>>>>>>>>>>>>>>>> If > > >>>>>>>>>>>>>>>>>>>> some > > >>>>>>>>>>>>>>>>>>>>>> data > > >>>>>>>>>>>>>>>>>>>>>>>> needs to be passed across, we > > >>>> should > > >>>>>>>> create a > > >>>>>>>>>>>> special > > >>>>>>>>>>>>>>>>> transfer > > >>>>>>>>>>>>>>>>>>>> object > > >>>>>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>>> this case. > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> D. > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> On Mon, Mar 13, 2017 at 9:10 > > >> AM, > > >>>>>> ALEKSEY > > >>>>>>>>>>> KUZNETSOV > > >>>>>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> well, there a couple of > > >> issues > > >>>>>>> preventing > > >>>>>>>>>>>>> transaction > > >>>>>>>>>>>>>>>>>>> proceeding. > > >>>>>>>>>>>>>>>>>>>>>>>>> At first, After transaction > > >>>>>>> serialization > > >>>>>>>>> and > > >>>>>>>>>>>>>>>>> deserialization > > >>>>>>>>>>>>>>>>>>> on > > >>>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>>>>>> remote > > >>>>>>>>>>>>>>>>>>>>>>>>> server, there is no txState. > > >> So > > >>>> im > > >>>>>>> going > > >>>>>>>> to > > >>>>>>>>>> put > > >>>>>>>>>>>> it > > >>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>>>> > > >> writeExternal()\readExternal() > > >>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> The last one is Deserialized > > >>>>>>> transaction > > >>>>>>>>>> lacks > > >>>>>>>>>>> of > > >>>>>>>>>>>>>>> shared > > >>>>>>>>>>>>>>>>>> cache > > >>>>>>>>>>>>>>>>>>>>>> context > > >>>>>>>>>>>>>>>>>>>>>>>>> field at > > >> TransactionProxyImpl. > > >>>>>> Perhaps, > > >>>>>>>> it > > >>>>>>>>>> must > > >>>>>>>>>>>> be > > >>>>>>>>>>>>>>>> injected > > >>>>>>>>>>>>>>>>>> by > > >>>>>>>>>>>>>>>>>>>>>>>>> GridResourceProcessor ? > > >>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>> пн, 13 мар. 2017 г. в 17:27, > > >>>>> ALEKSEY > > >>>>>>>>>> KUZNETSOV > > >>>>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> while starting and > > >> continuing > > >>>>>>>> transaction > > >>>>>>>>>> in > > >>>>>>>>>>>>>>> different > > >>>>>>>>>>>>>>>>> jvms > > >>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>> run > > >>>>>>>>>>>>>>>>>>>>>>> into > > >>>>>>>>>>>>>>>>>>>>>>>>>> serialization exception in > > >>>>>>>>>> writeExternalMeta > > >>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> @Override public void > > >>>>>>>>>>>> writeExternal(ObjectOutput > > >>>>>>>>>>>>>> out) > > >>>>>>>>>>>>>>>>>> throws > > >>>>>>>>>>>>>>>>>>>>>>>> IOException > > >>>>>>>>>>>>>>>>>>>>>>>>> { > > >>>>>>>>>>>>>>>>>>>>>>>>>> writeExternalMeta(out); > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> some meta is cannot be > > >>>>> serialized. > > >>>>>>>>>>>>>>>>>>>>>>>>>> пт, 10 мар. 2017 г. в > > >> 17:25, > > >>>>> Alexey > > >>>>>>>>>>> Goncharuk < > > >>>>>>>>>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Aleksey, > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I think I am starting to > > >> get > > >>>> what > > >>>>>> you > > >>>>>>>>> want, > > >>>>>>>>>>>> but I > > >>>>>>>>>>>>>>> have > > >>>>>>>>>>>>>>>> a > > >>>>>>>>>>>>>>>>>> few > > >>>>>>>>>>>>>>>>>>>>>>> concerns: > > >>>>>>>>>>>>>>>>>>>>>>>>>> - What is the API for the > > >>>>> proposed > > >>>>>>>>> change? > > >>>>>>>>>>> In > > >>>>>>>>>>>>> your > > >>>>>>>>>>>>>>>> test, > > >>>>>>>>>>>>>>>>>> you > > >>>>>>>>>>>>>>>>>>>>> pass > > >>>>>>>>>>>>>>>>>>>>>> an > > >>>>>>>>>>>>>>>>>>>>>>>>>> instance of transaction > > >>> created > > >>>>> on > > >>>>>>>>>> ignite(0) > > >>>>>>>>>>> to > > >>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>> ignite > > >>>>>>>>>>>>>>>>>>>>> instance > > >>>>>>>>>>>>>>>>>>>>>>>>>> ignite(1). This is > > >> obviously > > >>>> not > > >>>>>>>> possible > > >>>>>>>>>> in > > >>>>>>>>>>> a > > >>>>>>>>>>>>>> truly > > >>>>>>>>>>>>>>>>>>>> distributed > > >>>>>>>>>>>>>>>>>>>>>>>>>> (multi-jvm) environment. > > >>>>>>>>>>>>>>>>>>>>>>>>>> - How will you synchronize > > >>>> cache > > >>>>>>> update > > >>>>>>>>>>> actions > > >>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>> transaction > > >>>>>>>>>>>>>>>>>>>>>>> commit? > > >>>>>>>>>>>>>>>>>>>>>>>>>> Say, you have one node that > > >>>>> decided > > >>>>>>> to > > >>>>>>>>>>> commit, > > >>>>>>>>>>>>> but > > >>>>>>>>>>>>>>>>> another > > >>>>>>>>>>>>>>>>>>> node > > >>>>>>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>>>>>> still > > >>>>>>>>>>>>>>>>>>>>>>>>>> writing within this > > >>>> transaction. > > >>>>>> How > > >>>>>>> do > > >>>>>>>>> you > > >>>>>>>>>>>> make > > >>>>>>>>>>>>>> sure > > >>>>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>>>>>> two > > >>>>>>>>>>>>>>>>>>>>>> nodes > > >>>>>>>>>>>>>>>>>>>>>>>> will > > >>>>>>>>>>>>>>>>>>>>>>>>>> not call commit() and > > >>>> rollback() > > >>>>>>>>>>>> simultaneously? > > >>>>>>>>>>>>>>>>>>>>>>>>>> - How do you make sure > > >> that > > >>>>> either > > >>>>>>>>>> commit() > > >>>>>>>>>>> or > > >>>>>>>>>>>>>>>>> rollback() > > >>>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>>>>>> called > > >>>>>>>>>>>>>>>>>>>>>>> if > > >>>>>>>>>>>>>>>>>>>>>>>>> an > > >>>>>>>>>>>>>>>>>>>>>>>>>> originator failed? > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>> 2017-03-10 15:38 GMT+03:00 > > >>>>> Дмитрий > > >>>>>>>> Рябов > > >>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>> somefire...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Alexey Goncharuk, heh, my > > >>>>> initial > > >>>>>>>>>>>> understanding > > >>>>>>>>>>>>>> was > > >>>>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>>>>>>>>>> transferring > > >>>>>>>>>>>>>>>>>>>>>>>>> of > > >>>>>>>>>>>>>>>>>>>>>>>>>> tx > > >>>>>>>>>>>>>>>>>>>>>>>>>>> ownership from one node > > >> to > > >>>>>> another > > >>>>>>>> will > > >>>>>>>>>> be > > >>>>>>>>>>>>>> happened > > >>>>>>>>>>>>>>>>>>>>> automatically > > >>>>>>>>>>>>>>>>>>>>>>>> when > > >>>>>>>>>>>>>>>>>>>>>>>>>>> originating node is gone > > >>>> down. > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> 2017-03-10 15:36 > > >> GMT+03:00 > > >>>>>> ALEKSEY > > >>>>>>>>>>> KUZNETSOV > > >>>>>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Im aiming to span > > >>>> transaction > > >>>>>> on > > >>>>>>>>>> multiple > > >>>>>>>>>>>>>>> threads, > > >>>>>>>>>>>>>>>>>> nodes, > > >>>>>>>>>>>>>>>>>>>>>>>> jvms(soon). > > >>>>>>>>>>>>>>>>>>>>>>>>>> So > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> every node is able to > > >>>>> rollback, > > >>>>>>> or > > >>>>>>>>>> commit > > >>>>>>>>>>>>>> common > > >>>>>>>>>>>>>>>>>>>>> transaction.It > > >>>>>>>>>>>>>>>>>>>>>>>>> turned > > >>>>>>>>>>>>>>>>>>>>>>>>>>> up i > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> need to transfer tx > > >>> between > > >>>>>> nodes > > >>>>>>>> in > > >>>>>>>>>>> order > > >>>>>>>>>>>> to > > >>>>>>>>>>>>>>>> commit > > >>>>>>>>>>>>>>>>>>>>>> transaction > > >>>>>>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> different node(in the > > >>> same > > >>>>>> jvm). > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> пт, 10 мар. 2017 г. в > > >>>> 15:20, > > >>>>>>> Alexey > > >>>>>>>>>>>>> Goncharuk < > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >> alexey.goncha...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Aleksey, > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you mean that you > > >>>> want a > > >>>>>>>> concept > > >>>>>>>>>> of > > >>>>>>>>>>>>>>>> transferring > > >>>>>>>>>>>>>>>>>> of > > >>>>>>>>>>>>>>>>>>> tx > > >>>>>>>>>>>>>>>>>>>>>>>> ownership > > >>>>>>>>>>>>>>>>>>>>>>>>>>> from > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> one node to another? > > >> My > > >>>>>> initial > > >>>>>>>>>>>>> understanding > > >>>>>>>>>>>>>>> was > > >>>>>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>>>>>>> you > > >>>>>>>>>>>>>>>>>>>>>> want > > >>>>>>>>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>>>>>>> be > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> able > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to update keys in a > > >>>>>> transaction > > >>>>>>>>> from > > >>>>>>>>>>>>> multiple > > >>>>>>>>>>>>>>>>> threads > > >>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>>> parallel. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> --AG > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2017-03-10 15:01 > > >>>> GMT+03:00 > > >>>>>>>> ALEKSEY > > >>>>>>>>>>>>> KUZNETSOV > > >>>>>>>>>>>>>> < > > >>>>>>>>>>>>>>>>>>>>>>>>>> alkuznetsov...@gmail.com > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> : > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Well. Consider > > >>>>> transaction > > >>>>>>>>> started > > >>>>>>>>>> in > > >>>>>>>>>>>> one > > >>>>>>>>>>>>>>> node, > > >>>>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>>>>> continued > > >>>>>>>>>>>>>>>>>>>>>>>> in > > >>>>>>>>>>>>>>>>>>>>>>>>>>>> another > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> one. > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The following test > > >>>>>> describes > > >>>>>>> my > > >>>>>>>>>> idea: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ignite ignite1 = > > >>>>> ignite(0); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IgniteTransactions > > >>>>>>>> transactions = > > >>>>>>>>>>>>>>>>>>>> ignite1.transactions(); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> IgniteCache<String, > > >>>>>> Integer> > > >>>>>>>>> cache > > >>>>>>>>>> = > > >>>>>>>>>>>>>>>>>>>>>>> ignite1.getOrCreateCache(" > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> testCache"); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Transaction tx = > > >>>>>>>>>>> transactions.txStart( > > >>>>>>>>>>>>>>>>> concurrency, > > >>>>>>>>>>>>>>>>>>>>>>> isolation); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cache.put("key1", > > >> 1); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cache.put("key2", > > >> 2); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tx.stop(); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>> IgniteInternalFuture<Boolean> > > >>>>>>>>> fut = > > >>>>>>>>>>>>>>>>>>>>>> GridTestUtils.runAsync(() > > >>>>>>>>>>>>>>>>>>>>>>>> -> > > >>>>>>>>>>>>>>>>>>>>>>>>> { > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>> IgniteTransactions > > >>>>> ts = > > >>>>>>>>>>>>>>>>>> ignite(1).transactions(); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>> Assert.assertNull(ts.tx()); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>> Assert.assertEquals( > > >>>>>>>>>>>>>>>>> TransactionState.STOPPED, > > >>>>>>>>>>>>>>>>>>>>>>> tx.state()); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ts.txStart(tx); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Assert.assertEquals(TransactionState.ACTIVE, > > >>>>>>>>>>>>>>>>>>>>>>> tx.state()); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >> cache.put("key3", > > >>>> 3); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Assert.assertTrue(cache.remove("key2")); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tx.commit(); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return true; > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fut.get(); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >> Assert.assertEquals( > > >>>>>>>>>>>>>>> TransactionState.COMMITTED, > > >>>>>>>>>>>>>>>>>>>>>> tx.state()); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>> Assert.assertEquals((long)1, > > >>>>>>>>>>>>>>>>>>> (long)cache.get("key1")); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>> Assert.assertEquals((long)3, > > >>>>>>>>>>>>>>>>>>> (long)cache.get("key3")); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>> Assert.assertFalse(cache. > > >>>>>>>>>>>>>>> containsKey("key2")); > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In method > > >>>>> *ts.txStart(...)* > > >>>>>>> we > > >>>>>>>>> just > > >>>>>>>>>>>>> rebind > > >>>>>>>>>>>>>>> *tx* > > >>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>>> current > > >>>>>>>>>>>>>>>>>>>>>>>>> thread: > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* >
