Re: Optimistic/serializable transactions implementation

Agree with Sam here - we also reduce network calls since we don't need to notify for each failed tryLock, but only for cases when tx will definitely loose. Thanks! -- Yakov Zhdanov, Director R *GridGain Systems* www.gridgain.com 2015-10-16 10:22 GMT+03:00 Semyon Boikov : >

Re: Optimistic/serializable transactions implementation

Just one more question: "- transaction with greater order should always 'win' transaction with lower order" Greater order means "younger"? If it so, why should younger transactions win? Why not older? Or user will have possibility to configure this aspect of conflict resolution? On Thu, Oct

Optimistic/serializable transactions implementation

Hello, I'm working on new implementation for optimistic/serializable transaction mode (current implementation is inefficient and have bugs). This mode is supposed to be used when concurrent transactions do not update the same keys, in this case transactions can be executed more efficiently, but

Re: Optimistic/serializable transactions implementation

Jira issue is https://issues.apache.org/jira/browse/IGNITE-1607, branch ignite-1607 On Thu, Oct 15, 2015 at 10:58 AM, Alexey Kuznetsov wrote: > Semyon, could you please give a link to JIRA issue (if any) and what branch > contains your code? > > Also it is not clear for

Re: Optimistic/serializable transactions implementation

Semyon, could you please give a link to JIRA issue (if any) and what branch contains your code? Also it is not clear for me, how transaction order is assigned / calculated? If I start transaction t1 on none n1 and t2 on node n2, how it will be calculated? Thanks. On Thu, Oct 15, 2015 at 2:00

Re: Optimistic/serializable transactions implementation

> > is starvation possible here? > E.g. there are two nodes with GUIDs A and B. What will happen in the > following case: > 1) TX (A, 1) started and locked the key; > 2) TX (B, 1) started and waiting for lock; > 3) TX (A, 2) started and waiting for lock; > 4) TX (A, 1) released the lock. > 5) Who

Re: Optimistic/serializable transactions implementation

We did not decided yet exactly by which attribute transactions should be ordered, but logically it is better when wins older transaction or transaction having more keys. On Thu, Oct 15, 2015 at 11:18 AM, Alexey Kuznetsov wrote: > Just one more question: > > "-