i think this weird assoc was a leftover artifact from the old
event-fn stuff that i removed already? either way, performing an assoc
here is entirely useless so lets get rid of it
this is a change for functionality that will almost never, ever be used
in practice. but i just didn't like the idea of the 'aging-memory-store'
function creating a thread that you then had no control over whatsoever
after it returns ... maybe someone, somewhere will benefit from this.
if a number is not provided, then every time the sweeper thread body
executes, it will try to sweep the entire session, even if nothing
has read/written the session store in the mean time. this is also now
the default behaviour. the thinking here is that this allows for the
best real-time-feeling behaviour with regards to session expiry,
especially for low-traffic / low-activity web apps. applications
that care more about performance, can easily set a threshold here and
get the old behaviour back.
apparently this is a little bit faster than calling now once and then
passing it around as an argument. i have to admit i was not expecting
it to be a small but noticeable difference. i guess the JVM is really
able to optimize calls to System.currentTimeMillis() well?
of note is that there is now some possibility for very slight
discrepancies with the timestamps being set in a larger session map
across sweep-session calls (for example) because we are repeatedly
calling the 'now' function.
this is _probably_ not a big deal though.
the events function stuff always seemed very overkill to me. i cannot
think of any other criteria i've ever wanted for session expiry other
than "expire based on some period of idle time elapsing" and an event
function being used to provide this seems a bit too much to me.
thusly, this has all been replaced with a simple ttl value (specified
in seconds) as a non-optional argument to aging-memory-store.
also change the aging-memory-store opts parameter, it must now be an
explicit map if provided
Gered