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.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.
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).
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.
Righto.
--
Adam
