A little session talk

In the last week or so, I had to look into BlazeDS/LCDS code around session management which reminded me some of the questions I got on this topic, so decided to put a post together for some session talk.

In a traditional J2EE app, you probably have your JSP, a J2EE HttpSession that represents the JSP on the server, you set attributes on the HttpSession, get attributes from the HttpSession, and life is simple. However, in your non-traditional Flex/LCDS app, things are not so simple and this is mainly due to two reasons: First, a Flex client can talk to a LCDS server with multiple protocols at the same time (eg. HTTP polling and RTMP). Second, the NIO-based endpoints in LCDS live outside the Servlet-container, they are created and managed by LCDS NIO-server. This makes session management a little more complicated than a single HttpSession you get in a traditional J2EE app.

Let’s demystify the complexity but before we do that, I should point out the relevant LCDS 3.1 doc section on this topic that explains things like FlexClient, FlexSession, MessageClient and the relationship among them.

In a Flex/LCDS app, you have your MXML/AS that gets compiled into a SWF for client to use. That SWF is represented as what we call FlexClient on the server. When the Flex client connects to the LCDS server via a channel, a FlexSession is created (kind of like J2EE HttpSession) to represent the connection between Flex client and LCDS server. FlexSession is a superclass for a few other classes and it tries to hide different implementations due to protocol differences. You generally don’t need to deal with these subclasses and only work with FlexSession but I think it’s worthwhile to look into them so we get a better understanding of sessions in LCDS.

If your SWF uses a Servlet-based channel, meaning the non-scalable channels/endpoints supported only by BlazeDS (such as AMFChannel with AMFEndpoint), then the connection between the Flex client and LCDS server is represented by a HttpFlexSession. Since a Servlet-based channel is being used, the request goes through the Servlet container, and a J2EE HttpSession actually gets created for the client. HttpFlexSession simply serves as a wrapper for the underlying J2EE HttpSession. Any FlexSession#get/setAttribute calls are actually propagated to the J2EE HttpSession. This is nice because if you have a JSP in the same browser session as the Flex app, it’ll be able to access the session attributes set by the Flex app and vice versa.

On the other hand, if the SWF uses one of the scalable NIO-based channels/endpoints such as AMFChannel with NIOAMFEndpoint or RTMPChannel with RTMPEndpoint, then the request goes through the LCDS NIO server, rather than the Servlet-container. A J2EE HttpSession is not created, instead, LCDS creates NIOHTTPFlexSession or RTMPFlexSession (depending on the channel in use) to track the client on the server which are both independent of any J2EE session management. This means that calls to FlexSession#get/setAttribute are not propogated to J2EE. So, if you have a JSP in the same browser session as your Flex app, they won’t be able to share session data like they would have if the Flex app used a Servlet based channel/endpoint.

Are you out of luck when you use NIO-based channels/endpoints? Not really. You still have access to FlexClient object on the server, and FlexClient object has a list of sessions it is associated with. For example, if your Flex application uses a Servlet-based channel (let’s call this my-amf in short) and a NIO-based channel (my-rtmp in short), FlexClient will have 2 sessions in its list of sessions: One Servlet-based session (i.e. HttpFlexSession) for my-amf and one NIO-based session (i.e. RTMPFlexSession) for my-rtmp. Whenever you set an attribute on RTMPFlexSession, you can access the HttpFlexSession and set it there too. This way, not only all sessions associated with Flex client get the attribute, but a JSP in the same page would get the attribute in its HttpSession.

One important point. If you don’t care about sharing session data outside Flex (with a JSP for example), it’s good to know that FlexClient (the object that represents the SWF on the server) also has get/set/remove attribute methods. By setting/retrieving attributes on the FlexClient, you avoid the complexities of dealing with multiple sessions.

I plan to add a sample in lcds-samples to show how one can keep session attributes in sync across Servlet and NIO based sessions in the next release of LCDS.


2 thoughts on “A little session talk

  1. Hi Mete, thanks for the informative post. We folks at my company are facing a problem related to LCDS session management.

    We have a AIR client communicating with Java using LCDS remoting. The problem is that for multiple AIR clients we want that multiple instances of the Java remoting service should be created. But from what we have seen, all AIR clients are using the same instance of the Java remoting service. We are using “session” scope for the remoting destination, so it seems that multiple AIR clients are using the same Flex session.

    Any inputs on this would be highly appreciated.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s