• Persistence vs non-persistence web connection - web performance!
• Concerns of using cookie - security and size limitations
• Server side session management challenges in scalable web application
• Achieve linear scalability through stateless servers - start moving the session to the client

Today, I will start walking through all these topics at a high level. A series of articles will be written to further develop on each topic if necessary. Lets start!

Persistence vs non-persistence web connection

1. Before HTTP 1.1, HTTP is a stateless protocol that doesn't maintain persistence connection. Each request made by a Web browser, for an image, an HTML page, or other Web object, is made via a new connection.
2. HTTP 1.1 introduced persistence connection (ie. Keep-Alive) that Web browser can established a single connection, through which multiple requests could be made.
3. But before HTTP 1.1, how can state maintain across stateless HTTP request?
   
   • Normally, we keep the session in the server side and provide the session id to the client that can be used to link subsequent requests to the same session.
   • Normally, client (often time web client) will store the session id in cookie.
   • However, if the cookie is disabled, the session id will normally embedded in the URL (ie URL Rewriting).

Concerns of using cookie

What do we need to pay attention when we store info in cookie?

1. Size limitation and security concerns.
2. How long cookie can last? Default = expired when browser exits. In Java, you can do cookie.setMaxAge(int) with long future date if you want to keep the info lasting long in the cookie. If you do setMaxAge(0), it will void the cookie.
3. Normally, we don't keep all state info in cookie as the information could be sensitive and we are not able to protect it because it sits in the clients' filesystem. Apart from that, there has limitation in size as well. For these two concerns, we normally just store the session id in the cookie and keep the session in the server side. This approach can save us bandwidth as well.

Server side session management challenges

At the first glance, session in server side sounds like a great solution. However, when it comes to scale, it always raises the concerns. Imagine you need to replicate client session state across multiple servers to achieve high availability. Both the replication time and memory resource limit will cause your system not able to scale linearly. To solve or minimize this, we selectively pick what kind of info we store in the session, use sticky session to avoid one session replication across all the machine or even try to store the state to the client if possible like using rich client UI (ex. Flex and Silverlight). A post will be written about this topic later on.

Transient vs Persistent State

1. Session in the server can be timed out (~30 minute inactive)
2. Session in the server can be persisted in file across Tomcat restart.
3. Persistent state should be stored in database.
4. Object putting in session should be Serializable
5. Avoid putting too much info in the session b/c we don't want to put too much baggage during session replication. One server crash b/c of memory depletion can further spread across to other servers via session replication. Not Good! Should we reconsider storing session in client? This article talks about it.
6. Session replication is needed to support failover. Sticky session for simplicity but suffered data lost when the box is down. We can tell one or two servers as its backup to avoid the session lost. To go for sticky session approach, we need to identify the "sticky" part. What kind of thing we can use to link separate requests? Use IP address can potentially overload a box because some Internet service providers use a set of proxy servers to deal with many clients. This subject can be further developed. We will go back to it later!

Recently, I found out that Adobe has released BlazeDS (subset of LiveCycleDS) that has 4 main advantages:

1. AS3 to Java object communication (no XML passes back and forth is needed!)
2. Boost up performance b/c AMF is a binary protocol
3. Built-in proxy support that gets around the cross domain security issue from Flex in ease.
4. Allow push messaging

I have followed the guideline and set it up. Now my Flex application can call my Java object method without passing xml back and forth. It is awesome! During the setup process, you may experience your flex cannot find the destination set up in the server.

The trick here is to add a services argument to the mxmlc call, something of the form below should do the trick! 

-services “[local path to your java project]/WEB-INF/flex/services-config.xml”

Now you may start enjoying how AS3 talks to your Java Object. However, if  we bypass the Servlet layer in the code, how can we carry session across remote method calls? Great that I have found out how to handle it via this article. In short, you can access Session from your Java object via:

FlexContext.getFlexSession()

Here is the quote I got from the BlazeDS developer guide.

The FlexContext class is useful for getting access to the session and the HTTP pieces of the session, such as the HTTP servlet request and response. This lets you access HTTP data when you use a Flex application in the context of a larger web application where other classes, such as JSPs or Struts actions, might have stored information.

The FlexSession class provides access to an ID and also provides setAttribute and getAttribute functionality. This is useful for storing data on the server that doesn't have to go back to the client. However, FlexSession is not cluster-aware; if a client connects to a different server in the cluster, the client receives a new FlexSession. Nothing stored in the FlexSession attributes is persisted for clustering purposes. The FlexSessionListener class is useful for monitoring who is connected. You add a listener by using the static method to track new connections being made. You receive a reference to the session that was added. Each session can then report when it is destroyed to those same listeners. You use this for monitoring connections that close, and also to clean up resources.

When I looked into the source of FlexContext, I noticed that it leverages ThreadLocal to store context info like request, response and session.

    private static ThreadLocal sessions = new ThreadLocal();  
    /**
     * The FlexSession for the current request.  Available for users.
     */
    public static FlexSession getFlexSession()
    {
        return (FlexSession)sessions.get();
    }

Reference

Below are some of the useful references I have read so far:

1. Jim Boone's Blog