---
title:  Configuring Non-Sticky Sessions
---

<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements.  See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License.  You may obtain a copy of the License at

     http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->

This section describes the configuration of non-sticky sessions

## <a id="sticky_vs_non-sticky_overview__section_B2396FB0879248DBA85ADFDBBEFA987D" class="no-quick-link"></a>Why use non-sticky sessions?

Some situations require that sessions be 'non-sticky', which means that client requests are directed to any server in a cluster of application servers rather than returning to the same server with each request for a given client. Non-sticky sessions allow for more effective load balancing as a client operating in a model using sticky session replication will return to the same server each time regardless of load. To achieve a non-sticky session model, you must configure your deployment as described for the following modules/topologies.


**Note:**
Non-sticky sessions affect performance because sessions need to be re-created every time a request hits a different server. This may not be noticeable when the session attributes are small, but may become more evident as the session attributes increase in size and/or number.

## <a id="sticky_vs_non-sticky_overview__section_B2396FB0879248DBA85ADFDBBEFA987E" class="no-quick-link"></a>Configuring Non-Sticky Session Replication for Tomcat and TC Server

**Peer-to-Peer**

For peer-to-peer topologies, apply the following settings to enable non-sticky sessions to work correctly:

-   Java system property `gemfire.loadClassOnEveryDeserialization=true`. Set this property by editing the `bin/setenv.sh` file.
-   `prefer.deserialized.form=false`. Set this property in `conf/catalina.properties`.

**Client-server**

-   The Java system property `gemfire.loadClassOnEveryDeserialization=true` must be set, in the `bin/setenv.sh` file.
-   The local client cache must be empty. Ensure that the `gemfire.cache.enable_local_cache` property is set to false. This effectively sets the local client cache to be a **PROXY** cache.
-   If the local client cache is a **PROXY** cache, then expiration must be configured to notify the client via callback, which can be done by setting `gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK` to true. This allows the client cache to retrieve and expire the actual session object, resulting in more consistent behavior.


## <a id="sticky_vs_non-sticky_overview__section_E0E0E5A1C9484D4AA13878273F16A920" class="no-quick-link"></a>Configuring Non-Sticky Session Replication for WebLogic

**Peer-to-Peer**

No additional configuration is required.

**Client-Server**

-   The local client cache must be empty. Ensure that the `gemfire.cache.enable_local_cache` property is set to false. This effectively sets the local client cache to be a **PROXY** cache.
-   If the local client cache is a **PROXY** cache, then expiration must be configured to notify the client via callback, which can be done by setting `gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK` to true. This allows the client cache to retrieve and expire the actual session object, resulting in more consistent behavior.