If you always do whatever processing you are planning to do inside the CacheListener and use the "newValue" field that is supplied to that callback you will always begin processing in the order the data was received. I suppose if you want to ensure that you are completing processing in the correct order you would need to synchronize on your callback as you said.
To "prime the pump" you can use get as you are now, or registerInterest with a list of keys or wildcard on string-based keys. Register interest can optionally deliver the initial value followed by all updates in the correct order. -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Sat, Mar 4, 2017 at 7:58 AM, David Wales <davidmichaelwa...@gmail.com> wrote: > Hi there, > > I have a client proxy cache with an associated cache listener. An > invocation of the region get method will trigger the afterCreate callback. > I realized this call back was on the same thread that called get and is > different to the thread that dispatches the region updates. So I had a look > at the code and there seems to be no synchronization. I could mark the > cache listener methods as synchronized but this doesn't fully mitigate the > race. How does one get the initial state of an entry in a region in a way > that synchronizes with updates on. Is this a known limitation or a bug as > the documentation talks about cache listener methods being mutually > exclusive? > > Much appreciated > Thank you > David >
