Monday, 22 February 2016

ColdFusion 2016: Unaspirational thinking with session/Redis support

Disclsoure: this is a reproduction of an observation I made on the ColdFusion 2016 pre-release forums. As it is my own work, and is independent of anyone else's comment or input, I feel it's not breaking the NDA to repeat it.

ColdFusion 2016 adds a new feature to be able to pass-off session storage to a Redis server. Details here: ColdFusion 2016 Features / External session storage. The allows one to specify in CFAdmin a Redis server to use for session management.

On the face of it this is a good feature, but I had apprehensions about this since it was announced. To contextualise the first sentence, I had earlier speculated that the implementation would not be very well thought out.

Right, so here we are, and my suspicions were correct.

This implementation is somewhat lacking in aspiration.

[redacted]Adobe have implemented half a solution here.

What would have been a good approach would be to have provided an interface which one can implement a SessionManager connector. And then have this sort of thing in Application.cfc (or in the CF server config somewhere for instance-wide handling):

this.sessionManager = new MySessionManager();

This hands off all session management to the SessionManager.

The interface specifies which methods are needed to use sessions via the abstracted manager, eg:
  • createSession()
  • setProperty()
  • getProperty()
  • hasProperty()
  • getProperties()
  • invalidateSession()
  • expireSession()
  • onSessionStart()
  • onSessionEnd()
  • etc, you get the idea

I s'pose this interface could be fulfilled either by a Java class or a CFC.

From there, Adobe could implement a redis-based SessionManager.

Why? Because there’s more games in town than Redis. A lot more. We have a cluster of Memcached boxes which we could use for this, had Adobe not painted itself (and all of us) into a corner. Again. Even from the perspective of existing CF work... why Redis, when all the rest of the embedded nearline storage has been build on Ehcache? Or, hey... I might wanna put my sessions in a DB, or even have a null implementation.

But the way Adobe have implemented this we're stuck with their one implementation. And at their mercy for how it’s implemented.

Also I think - as a general thing - the primary configuration mechanism for a CF server/instance/application needs to move away from the CFAdmin interface. That approach to configuring application server software is a bit out of date. Config should be file based, IMO (and not WDDXed structs, but clear text, human- and code-maintainable config files).
I removed one sentence from that as it alludes to something else on the PR which I am not in the position to discuss here, I have also corrected two typos I spotted, and added some formatting.

A coupla notes on this:

  • as I mentioned: seemingly this can only be managed by CFAdmin. I think this should be settable at Application level.
  • As mentioned in the docs: "If you select Use J2EE session variables, you cannot store ColdFusion sessions in Redis". This is not very satisfactory. This was discussed in the pre-release, but I cannot go into that here. erhaps the relevant people from Adobe can reproduce their feedback on this.

I've not much to add other than that... I have not experimented with or tested this feature, so I don't know how robust or production-ready it is.

It's certainly not an enterprise solution to the functionality though.