J2EE Session Variables

I mentioned in the previous note on New URLSessionFormat() Function that CF now supports "J2EE sessions". What are they? And why would you care? Well, as a coder, it's possible that they'd only add benefit and, again, there's little reason not to use them. Again, it's a feature set in the CFMX Administrator, in the "memory variables" page, checking the "Use J2EE session variables" option and restarting the server.

As mentioned, J2EE sessions work by sending to the client a cookie not with CFID and CFTOKEN but instead JSessionID. (Actually, if CFAPPLICATION has CLIENTMANAGENT="yes", then the CFID/CFTOKEN pair are still sent, to support client variables only.)

There's more to the difference between the CFID/CFTOKEN pair and JSessionID than just the name. First, the JSessionID value is a more elaborate combination of characters (including a UUID). As mentioned in the previous note on Optional UUID for CFTOKEN, the default CFID/CFTOKEN pair are simply a few numbers each. That makes them easy to guess. That previous note showed that you can change the CFTOKEN to use a UUID, so that benefit may seem diminished.

But there are still more differences, and they can be very important to some. First, and coolest of all, is that J2EE sessions work the way most developers have long wished CF session variables would: when your user closes their browser, the session is terminated as well. Halleluiah!

Actually, to be completely accurate, it must be said that the session closes when the last browser instance open is closed. If the user has opened several Netscape windows, for instance, then only when they’ve closed them all will the session terminate. All Netscape windows share the same JSessionID.

With Internet Explorer, things are a little trickier. If multiple windows have been opened with the File>New>Window command or Ctrl-N keyboard shortcut, they'll share the same session and closing them all will terminate that session. But if you open an IE window with Start>Programs>Internet Explorer (or click the IE icon in the task bar launcher), that will open a new session.

Therefore, it's possible to have sessions for some windows terminate when closed while still having other IE windows open. But, again, closing them all will terminate any sessions with J2EE session variables enabled.

How does the mechanism work that allows the session to terminate when the browser is closed? Some may have already guessed it: the JSessionID that’s used for J2EE sessions is set as a non-persistent (or “per-session” or “temporary”) cookie. That means simply that the cookie value is not stored persistently in the browser user’s hard drive. It’s held only in the browser’s memory. So when the browser (all its instances) is closed, the JSessionID is lost. On the next visit by that user in a new browser window, they are given a new JSessionID.

This also points out that another benefit of using J2EE sessions for those organizations that are not allowed to use persistent cookies (such as the CFID and CFTOKEN cookie values set by CFMX and previous versions). These organizations can use J2EE sessions much more easily than they could CF-based sessions. There are ways in all releases of CF that they could force the CFID and CFTOKEN to be non-persistent, as outlined in the Macromedia Technote at http://www.macromedia.com/v1/Handlers/index.cfm?ID=21079&Method=Full. With J2EE sessions, they need not bother with that.

One final benefit of using J2EE sessions, which may or may not impress most CF developers, is that using them allows sharing of session variables with JSP and servlet programs also run under CFMX. That could be valuable, if you start exploring that capability.