Invalidates will only happen if you explicitly do them or configure a feature (like expiration) to use them. The atomicity will probably not be what you want. Basically the default method code is all being done from your client. This will probably result in multiple messages being sent to the server for each Region method the default code calls. They are built on top of the methods available before 1.8. These methods kind of snuck in without our notice due to them being added as default methods on an interface we already implemented. So geode does not have any tests for them.
On Tue, Jul 3, 2018 at 3:24 PM <[email protected]> wrote: > Hi, > > Thank you for your quick reply. > > With regard to the issues highlighted in Jira, please could you confirm > the following: > > 1) Is there any anticipated impact to the atomicity of the operations? > > 2) As stated the operations are not compatible with invalidated entries in > a Region. Apart from a client specifically calling invalidate, are there > any reasons why Geode would internally invalidate an entry? i.e. assuming > invalidate is not called by a client and values are always non-null would > the ConcurrentMap operations be safe to use? > > Thanks again for your help. > > Kind regards, > Phil > > On Tue, 3 Jul 2018, 17:33 Darrel Schneider, <[email protected]> wrote: > >> You are right that in the current geode releases, the ConcurrentMap >> methods added since java 1.8 just use the default implementations provided >> on the interface. >> Some issues with this have been identified but so far no changes have >> been made. You can read more about this: >> https://issues.apache.org/jira/browse/GEODE-2727 >> >> On Tue, Jul 3, 2018 at 6:46 AM <[email protected]> wrote: >> >>> Hi, >>> >>> I currently have a Geode client/server topology with a partitioned >>> region. I'm looking to make use of ConcurrentMap operations from inside the >>> client (PROXY region). >>> >>> The JavaDoc on the Region interface states: >>> >>> The semantics of the ConcurrentMap methods on a Partitioned Region are >>> consistent with those >>> * expected on a ConcurrentMap. In particular multiple writers in different >>> JVMs of the same key in >>> * the same Partitioned Region will be done atomically >>> >>> >>> This suggests that all ConcurrentMap operations are performed atomically >>> when there are multiple writers in different JVMs (clients). I noticed in >>> the Region interface that there is a specific declaration of the >>> putIfAbsent method but no declaration of other ConcurrentMap methods such >>> as compute and merge. >>> >>> Please can you confirm if all ConcurrentMap methods (specifically compute >>> and merge) provide guarantees around atomicity as it looks like they simply >>> use the default implementation defined in ConcurrentMap. >>> >>> Thanks in advance for your help. >>> >>> Kind regards, >>> Phil >>> >>> >>> >>> >>>
