3-3:Session_storage

Contents Railo Session Storage What is necessary in order to use the session storage What are the benefits? What are the downsides? Client Storage

Railo Session Storage

This is one of the more important improvements in Railo 3.3. This feature allows you to store a Railo session inside a defined cache. As a cache you can use all possible caches that you have available inside the Railo Administrators. This of course opens huge perspectives. Storing a session for instance in a NoSQL database like CouchBase means that the session is not stored in the local JVM anymore and therefore not lost if the server crashes or is restarted. This is mostly the problem when you want to update your server or you have stability problems. Due to the fact that sessions will be lost you do not dare to upgrade the server or you think about clustering even though it is not necessary regarding traffic. So it would make sense to use the sessionstorage and take care of the problem.

What is necessary in order to use the session storage

In fact there are only two things you need to do:

1. Define a cache and activate the checkbox called Allow to use this cache as client/session storage.. This is necessary so that Railo knows how to treat entries made into this cache. They will be automatically serialized and deserialized into the session scope.
2. You need to set the Application.cfc or Application.cfm attributes sessionstorage and sessioncluster in order to activate the sessionstorage feature.

The difference between the sessionstorage and the sessioncluster attribute is that the sessionstorage defines which one of the defined cache names Railo should use and the attribute sessioncluster tells Railo to read the session from the cache on every request and write it to the cache after the request has finished. If you do not define the second attribute, Railo will only read the session from the cache if it is not already in memory and only write it to the cache after a request finished if a change to the session has been made. So defining the second attribute is best suitable for round robin clusters since then the session is maintained across requests and servers.

Example:

component {
...

// this cache is set in railo admin and flag "storage" is enabled
this.sessionStorage="mycachename";
this.sessionTimeout = createTimeSpan(0,0,30,0)
}

The default storage (when nothing is defined) is "memory".

Sessions are always kept in memory and backed up to a storage. If a session is not available in memory, Railo will first check the storage for an available one and load it if it is there. This allows sessions to be maintained even across engine restarts. If no object is found in the storage, Railo will create a new session.

What are the benefits?

Like for the client scope, if a storage backend is used for the session scope, idle object will be removed from memory after about 5 minutes. If the information is needed again later, the session data is read from the defined storage backend. This can reduce the memory footprint of an application a lot! Furthermore, a session can survive a restart of the server, even the "onSessionEnd" is executed after a restart of the server! Also, this feature can be used to build simple (and later on advanced) cluster enviroments (read more below).

What are the downsides?

You can only store objects in the session scope that can be serialized by the storage backend used. If an object is stored in cache and loaded again, it is a clone of the original source object, which means that references to objects in other scopes are gone. When you use the session storage the application.cfc event onSessionEnd will not be triggered. That's because the session data may not be stored on the server and thus it's not clear which server to call for the onSessionEnd event.

Sticky sessions cluster - no use of the sessioncluster attribute If you set the attribute sessioncluster to false an object is only read from the storage if it isn’t found in memory. This is sufficient if you work with sticky sessions which send the request of a certain user always to the same server in the cluster. If the load-balancer would work in a round-robin fashion and send the user to both Railo instances, the result would be that for instance at first "Railo2" would read the session object from the external store as expected. It would also update the information according to what happened in the current request. However, if the user upon the next request would then be sent to "Railo1" again, all changes made to the session would be lost because “Railo1” already has an object in memory and thus would not read the updated information from the storage. You might think that there are only downsides to this setup, but the performance is better in this scenario since only a write operation (onRequestEnd) needs to be performed which can even be asynchroneously, so that the overall performance is not touched. If you on the other hand use the attribute sessioncluster and set it to true, every request reads the session from the cache first.

In order to make use of the clustered sessionstorage, you need to enable it by setting the attribute:

this.sessionCluster = true
... or ...
this.clientCluster = true

Client Storage

Railo 3.2 already supported different storage types for the client scope (file, datasource, memory, cookie). In Version 3.3 you now can define a cache source (ram cache, ehcache, ehcache lite, memcached, couchdb ...) as the storage type, simply by defining the name of the cache with the property clientStorage. And also note that the client scope in Railo also can store complex data.

Example:

component {
...

// this cache is set in railo admin and flag "storage" is enabled
this.clientStorage="mycachename";
}

You need to set the flag "storage" of the cache definition in the railo admin to make it work. In addition you can now define the timeout of the client scope (default 90 days) as follows:

Example:

component {
...

// default value when not set is 90 days
this.clientTimeout = createTimeSpan(180,0,0,0)
}

The default storage (when nothing is defined) is still "file", storage type "registry" is still not supported and is interpreted as an alias for "file".