Mike, With distributed ack (default for PartitionedRegion), the put operation is not returned (to calling thread) until the events are added to the client subscription queue...And in the subscription queue, we check for out-of-order events....
-Anil. On Mon, Mar 14, 2016 at 1:18 PM, Michael Stolz <[email protected]> wrote: > Even if it's across 2 separate regions and the primaries aren't even > located on the same machine? > I don't think our guarantee of ordering goes that far. > > Two puts on the same key in the same region, yes they will be received in > order. > > Two puts on same or different keys in *different* regions, I don't > believe so. > > > -- > Mike Stolz > Principal Engineer, GemFire Product Manager > Mobile: 631-835-4771 > > On Mon, Mar 14, 2016 at 4:14 PM, Anilkumar Gingade <[email protected]> > wrote: > >> If its the same thread that did the put; the client (any) will receive it >> in order...We guarantee event ordering at thread level... >> >> -Anil. >> >> >> On Mon, Mar 14, 2016 at 12:59 PM, Michael Stolz <[email protected]> >> wrote: >> >>> I'd say there's a pretty good chance of the ordering being different for >>> two different regions. >>> >>> -- >>> Mike Stolz >>> Principal Engineer, GemFire Product Manager >>> Mobile: 631-835-4771 >>> >>> On Mon, Mar 14, 2016 at 3:52 PM, Randy May <[email protected]> >>> wrote: >>> >>>> Suppose in a client, I do two puts in a particular order: >>>> >>>> regionA.put(K,V); >>>> regionB.put(K,V); >>>> >>>> If another client has registered interest on both regions, is there any >>>> guaranty about the order in which those 2 events are received on that >>>> client ? If the client is using local cache, could there be a time when >>>> region B contains the new value but region A contains the old value ? >>>> >>>> >>> >> >
