Dear Geode, It seems that issue seen in GEODE-7477 is only for the Tomcat Testing (which overrides the default setting.)
So current Geode implementation for default configuration is correct for Tomcat module. So we do not need to discuss whether we should change the implementation based on the above mentioned pros and cons. User could override the setting in the context.xml if needed. Let's close this discussion. Regards, Eric On Tue, Nov 19, 2019 at 5:05 PM Eric Shu <e...@pivotal.io> wrote: > Dear Geode, > > Here is the current documentation on enableLocalCache for default > configuration in Tomcat module (Changing the Default Geode Configuration > in the Tomcat Module > <https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html> > ) > > *enableLocalCache*Whether a local cache is enabled. If this parameter is > set to true, the app server load balancer should be configured for sticky > session mode. > > Default: false for peer-to-peer, true for client/server > However, the current default implementation actually is false as well for > client/server. Please see GEODE-7477 > <https://issues.apache.org/jira/browse/GEODE-7477> > > I want to start a discussion to see what should be the default setting for > client/server. > > Here are the pros and cons for setting enableLocalCache to true or false > for client/server: > When it is set to true: > Pros: fast session retrieve. (no need to retrieve the session object from > Geode servers) > Cons: possible stale data retrieved (different Tomcat instance could > return different values for the same session Id, as client cache could > receive updates from servers through HARegionQueue. There could be delays > occurred if load on servers are high and cause the queue to build up.) Even > though sticky session mode is enabled, there still could be a failover > scenario to occur. > > When it is set to false: > Pros: always go to server to retrieve the session object (no data > inconsistency) > Cons: It requires sending messages to retrieve the session object from the > server. > > I think we should keep the current implementation and change the > documentation accordingly, because I think user may prefer data consistency > (vs eventual consistency). If we fix the issue based on current > documentation there will be a change of behavior for the current user > applications. > > Regards, > Eric > > >
