Looks like ordering semantics is the most critical part of this algorithm :-) If we are really bothered with possible starvation, then neither topology version, nor local order, node ID or keys count could help us. Any combination of them allows for olders TXs to be postponed by newer. May be GridCacheVersion.globalTime will do the trick?
On Thu, Oct 15, 2015 at 11:32 AM, Semyon Boikov <[email protected]> wrote: > 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 < > [email protected]> > wrote: > > > 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 15, 2015 at 3:07 PM, Alexey Goncharuk < > > [email protected]> wrote: > > > > > 2015-10-15 10:58 GMT+03:00 Alexey Kuznetsov <[email protected]>: > > > > > > > > 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? > > > > > > > I believe that we can utilize nearXidVersion for this ordering (or some > > > sort of it's modification). Since cache version contains local order, > > > topology version and node ID and also is comparable, it is guaranteed > > that > > > nearXidVersion is always unique and there is always an unambiguous > order > > > between any two Xid versions. > > > > > > > > > > > -- > > Alexey Kuznetsov > > GridGain Systems > > www.gridgain.com > > >
