ColdFusion sessions vs J2EE sessions

Question

Are there any benefits to ColdFusion sessions vs J2EE sessions?

The ColdFusion session documentation mentions the benefits of J2EE sessions, but not any advantages of ColdFusion sessions. J2EE sessions have been available since ColdFusion MX (released in 2002), but there are still a lot of people using standard ColdFusion sessions. Are there any disadvantages of J2EE sessions that aren't present with ColdFusion sessions?

J2EE session management provides the following advantages over ColdFusion session management:

• J2EE session management uses a session-specific session identifier, jsessionid, which is created afresh at the start of each session.
• You can share session variables between ColdFusion pages and JSP pages or Java servlets that you call from the ColdFusion pages.
• The Session scope is serializable (convertible into a sequence of bytes that can later be fully restored into the original object). With ColdFusion session management, the Session scope is not serializable. Only serializable scopes can be shared across servers.

Therefore, consider using J2EE session management in any of the following cases:

• You want to maximize session security, particularly if you also use client variables
• You want to share session variables between ColdFusion pages and JSP pages or servlets in a single application.
• You want to be able to manually terminate a session while maintaining the client identification cookie for use by the Client scope.
• You want to support clustered sessions; for example, to support session failover among servers.

Answer 1

There are no serious disadvantages to using Java EE session cookies, and there are some advantages to using them, as indicated above in your question.

The one disadvantage to Java EE tokens is that the cookies cannot be easily modified programmatically. CF Tokens can. You can modify CF Tokens to be session only. You can also modify them to be SSL-only and httpOnly.

You can make Java EE tokens SSL-only and httpOnly as well, but it involves JVM arguments.

In CF9, Adobe also improved the randomness of CF Tokens to be more on par with Java EE tokens.

I really don't think it matters which one you use (assuming you're on CF9 or higher). But Java EE Tokens are the closest to working securely out-of-the-box. But if you want to go beyond just setting the cookies to "session-only" and have them be SSL-only and httpOnly, you'll need to dig into the JVM settings. You cannot do that in your App.cfc.

Answer 2

CF native sessions don't use Session cookies, so can last across browser/machine restarts, whereas all Java EE servers by default use session cookies,so your session can only last as long as your browser is open.

I can't find where this behaviour is specified in the Servlet JSR, but in Servlet Spec 3.0 (i.e. not JRun) , you can set an expiry date for your Java EE session cookie in order to mimic the CF native session behaviour.

As nosilleg mentions, this is could be a bonus, but also could be seen as a security problem, depending on the security requirements of the app your're working on.