Re: Support for starting transaction in another thread IGNITE-4887

So, desired behavior is the following: when some thread evaluates tx operation's secured scope, other threads should be locked and then released with return after first thread has finished evaluating secured scope ? пн, 3 июл. 2017 г. в 17:12, Yakov Zhdanov : > Yes, feel

Re: Support for starting transaction in another thread IGNITE-4887

So i need to put new lock mechanism to* all* transaction operations ? If so, don't we need additional ticket for this ?(for example sub ticket for my original one) пн, 3 июл. 2017 г. в 16:59, Yakov Zhdanov : > Disagree. Currently transaction is bound to a thread and if user

Re: Support for starting transaction in another thread IGNITE-4887

Disagree. Currently transaction is bound to a thread and if user tries to pass it over to another thread this would be a contract violation. Your ticket will make inter-thread transitions allowed. --Yakov

Re: Support for starting transaction in another thread IGNITE-4887

It is a global scope) Now multiple threads can commit transaction and it will lead to exception. It doesn't refer to my ticket only, but for a current transaction implementation. пн, 3 июл. 2017 г. в 16:53, Yakov Zhdanov : > What separate ticket do you mean here? I think

Re: Support for starting transaction in another thread IGNITE-4887

What separate ticket do you mean here? I think this is the scope of the original one. --Yakov 2017-07-03 16:39 GMT+03:00 ALEKSEY KUZNETSOV : > I've go a test, which illustrates transaction commit fail when multiple > threads try to commit. As i said, it happenes in

Re: Support for starting transaction in another thread IGNITE-4887

I've go a test, which illustrates transaction commit fail when multiple threads try to commit. As i said, it happenes in mvcc stage. So we should create a special lock mechanism for all transaction methods. In a separate ticket. пн, 3 июл. 2017 г. в 16:26, Yakov Zhdanov : >

Re: Support for starting transaction in another thread IGNITE-4887

>Consider thread *Th1* started transaction *Tx1*, done some actions, and is >calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And >concurrently thread *Th2 *is calling the same commit on* Tx1*. Alexey, this looks weird to me. IMO, if we talk about proper implementation you

Re: Support for starting transaction in another thread IGNITE-4887

would lead to exception. > > So, there is no locking sections (mutex) here > > -- Forwarded message - > From: Yakov Zhdanov <yzhda...@apache.org> > Date: пн, 3 июл. 2017 г. в 14:16 > Subject: Re: Support for starting transaction in another thread IGNITE-4887 &g

Support for starting transaction in another thread IGNITE-4887

hich would lead to exception. So, there is no locking sections (mutex) here -- Forwarded message - From: Yakov Zhdanov <yzhda...@apache.org> Date: пн, 3 июл. 2017 г. в 14:16 Subject: Re: Support for starting transaction in another thread IGNITE-4887 To: ALEKSEY KUZNETSOV <alkuznet

Support for starting transaction in another thread

Hi, Igniters! This is a subtask for "distributed transaction of non-single coordinator" task. Will appreciate your thoughts on it. ticket : https://issues.apache.org/jira/browse/IGNITE-4887 and a commit : https://github.com/voipp/ignite/commit/aa3487bd9c203394f534c605f84e06436b638e5c -- *Best

[jira] [Created] (IGNITE-4887) Support for starting transaction in another thread

Alexey Kuznetsov created IGNITE-4887: Summary: Support for starting transaction in another thread Key: IGNITE-4887 URL: https://issues.apache.org/jira/browse/IGNITE-4887 Project: Ignite