> Sorry for the delay in getting back to you--I did some experimentation and
> confirmed with Andy that indeed there is a separate process that runs every
> 5 minutes to check for expired sessions. So in theory the longest you'd
> ever have to wait (meaning you hit it immediately after the session
> expiration process runs) for the session to expire would be 5 minutes. And
> of course if you hit it at the tail end of the cycle, you might see it
> times out "correctly" if you have a very low session timeout set.
This explains exactly what I see .....
> Andy's looking at the fact the CFID and CFTOKEN stay the same after
> expiration, but in my experimentation the session count definitely
> decreases after the session expires, increases again when I refresh a page
> with a session dump on it, but the ID and token stay the same.
CFID & CFTOKEN indeed stay as is .... that is what I indeed see. They
are being re-used.
> What DOES happen in that scenario is that after the session expires, any
> session data OTHER than the CFID and CFTOKEN does go away. So for example
> if a session starts and you do <cfset session.foo = "bar" /> then while the
> session is active if you dump the session, you'll see that variable in the
> dump. After the session expires the CFID and CFTOKEN will be the same as
> they were before, but session.foo will no longer exist. So in short the
> session does get expired, it just retains the same CFID and CFTOKEN.
Sorry, this is where I do not agree. This is what I have in
Application.cfc:
<cfset this.name = "appname">
<cfset this.sessionmanagement = "Yes">
<cfset this.setclientcookies = "Yes">
<cfset this.sessiontimeout = CreateTimeSpan(0,0,0,5)>
<cffunction name="onSessionStart">
onSessionStart
<cfset session.start = now()>
</cffunction>
So I output something, so I can see when it comes through the
onSessionStart. And I set a session var. Now on the page, when I
reload after 5+ seconds, I can see that it doesn't come through the
onSessionStart and the session.start has not been updated. So it
hasn't timed out. When I wait longer, 5+ minutes, I reload, I then see
the onSessionStart being triggered and session.start is fresh. CFID &
CFTOKEN are indeed unchanged.
I still have to think that there is a bug: timed-out sessions who are
still in memory and re-used, are not checked to see if they are timed
out. If they still exist, they are being re-used. I depends on the
other process to actually clear them from server memory. And that
process is the one and only that looks at the time-out value.
> Ultimately you may, as Alex suggested, want to look into using J2EE session
> variables since those get nuked when you close the browser.
Well, that is exactly what I did. I enabled J2EE sessions and then the
above is working perfectly. Session timeout is exactly the amount of
seconds that I set it. J2EE work as I expect this to work. Very nice.
But openBD > system info shows "0 active sessions" .... I guess that
is not working for J2EE sessions.
Anyway, with this knowledge I know what to expect and can decide how
to use them. Thanks for thinking with me on the subject.
> Main reason is because depending on where you store them of course it's a
> lot of extra overhead for (again, depending on the application in question)
> negligible benefit.
>
> This is a great summary of why they're generally not a good
> idea:http://www.dopefly.com/pages/ColdFusionClientVariablesFinalNail.cfm
That article makes a lot of sense. Thanks for that. But even the
author doesn't think they are useless, it is just that the way they
are implemented is crap. Well, wouldn't it be a nice one for openBD to
do it better then :-) So not client vars as Adobe does them, but
really as session-in-database like e.g. give more control when and how
they are actually being read and especially write. Which more like
sessions, but then sessions-in-database. And only when you actually
define them and not always.
OpenBD already has the checkbox to disable the client update stuff,
which is also mentioned in the article, so that is an improvement.
> There's a million ways to skin that cat so it would be helpful to know more
> specifics about your application if you're interested in discussion some
> alternatives.
Well, I think I know the answer now, after reading that article, but
let me give it a try. We have a webshop with shopping basket, hosted
on two app servers with one database server and load-balancer in
front. Instead of taking the "lazy" approach of client variables, we
should build a special component store-shopping-basket-in-database,
which is only being used when a shopping basket is needed (which is
certainly not everybody). An alternative would be to distribute-
session-over-cluster (as Alex suggests) or have session-stick-to-node
enabled in the cluster.
--
online documentation: http://openbd.org/manual/
google+ hints/tips: https://plus.google.com/115990347459711259462
http://groups.google.com/group/openbd?hl=en
Join us @ http://www.OpenCFsummit.org/ Dallas, Feb 2012
