ApplicationInvalidate & ServerInvalidate

language
1

@micstriit and I have been discussing this last week, a Rasia client has sponsored some new functionality along the lines of

  • ApplicationInvalidate(); // end application, including clearing out all the application's sessions
  • ServerInvalidate(clearApplications=true/false, clearSessions=true/false)

in the spirit of the god old SessionInvalidate() :: Lucee Documentation (see LDEV-4166)

being able to optionally able to not call the listeners ( onSessionEnd / onApplicationEnd ) is something we are considering

then @AdamCameron goes off quite timely as it happens and blogs about something related we had been looking to address as part of all this

which is basically
LDEV-982 applicationStop() removes application scope for long-running page threads
which causes
LDEV-3613 ApplicationStop() race condition
which also relates to
LDEV-4166 onSessionEnd() never triggered using SessionInvalidate()
LDEV-3478 onSessionEnd() never triggered using sessionRotate()
and this slightly related quirk
LDEV-3388 pagePoolClear/InspectTemplates etc are per mapping, but they only address the current Application’s mappings

and of course @bennadel might have possibly blogged about this too

4 Likes
2

Are all those existing issues going to be addressed as part of this new work?

I note that LDEV-982 is now over 6 years old!
I’m NOT a true java dev - but know enough to be dangerous!
Is there anything specific I can help with?

3

nah, I just mentioned them for shit’s n giggles! of course they will be

4

Awesome - the offer still stands - if you / anyone think of something I can help with - please ask!

1 Like
5

ServerInvalidate() is perhaps a contradiction, because the function cannot be called within the context of an application. As such, I don’t think Lucee should implement it.

Let me illustrate with a metaphor. I am my application, you are yours. Even though we’re within the same server scope, my responsibility is limited to me, yours to you. We can therefore not interfere in each other’s affairs, let alone stop or clear each other.

That leaves only one possible place for ServerInvalidate(), namely, Server.cfc. But then, the Server.cfc instance exists only once, and runs when the server starts. Which altogether makes ServerInvalidate() unnecessary.

2 Likes
6

To me there is no need for ApplicationInvalidate(), given that Lucee already has ApplicationStop(). My only reason is Occam’s Razor as design principle.

All that needs to be done is:

  1. Resolve any outstanding issues with ApplicationStop() ;
  2. Ensure that ApplicationStop() does the following: end the current application, invalidate and clear out the application’s sessions, and restart a new application.
1 Like
7

^^^ good point re serverInvalidate.

It’d be like writing an onSessionEnd handler that also calls applicationStop. Semantically: it makes no sense. Does it?

Maybe instead of jumping forwards all the way to the solution, it might be helpful if you share what problem yer trying to solve, @Zackster.

Now that I think about it, I’m not sure the parallel between sessionInvalidate and this suggested applicationInvalidate really holds.

I think one needs to look at sessionInvalidate in the context of sessionRotate, and what the two functions are trying to do. They are about the association of a client user to a server session, and are about “experience personalisation and continuity”, and the ability to renew or end that continuity. There is no such parallel at application level I think. The application starts, but it has no “personality” or individuality after that.

That’s not to say the desire to end an application and its sessions is not valid: it definitely is. I just am not sure the mooted nomenclature / metaphor holds.

Might this be a variant in behaviour of applicationStop? I’m generally loath to suggest boolean flag params, but might applicationStop(boolean stopSessions=false) be reasonable here? Although its usage would be applicationStop() and applicationStop(true). Without knowing already, what does true mean here? Bleah. This is why boolean flag params are rubbish. A way around this would be to have a system constant END_SESSIONS (the value of which would be true), so one would use: applicationStop(END_SESSIONS). This is not idiomatic CFML though.

The alternative “clean code” approach would be to have a different function, but applicationAndItsSessionsStop sounds rubbish.

Even if we were to “fix” CFML’s yoda-speak and have stopApplicationAndSessions it’s still not great. And also breaks “sideways compat” with applicationStop anyhow.

Back to applicationInvalidate. If we were to add that, Lucee’s CFML would have applicationStop and applicationInvalidate. The difference being one ends sessions too, the other doesn’t. For someone not part in this conversation, how does one tell which does which, without checking? Nothing about either name suggests any difference in behaviour regarding sessions.

I think this is one of those “naming is hard” things.

And I’m sorry I’ve only been able to go “I don’t like any of these”, without coming up with a good alternative :frowning:

8

That’s called er documentation, we’d make this clear in the docs

9

It’s an interesting idea. Since we’ve moved to Docker at work, I don’t usually have to invalidate anything - the next “deployment” will just wipe-out everything and start over. That said, I do still use applicationStop() from time-to-time, but that’s usually when something like a mapping or a per-app setting gets cached in such a way that the server simply doesn’t want to update it (never sure why that happens), and I have to stop the app to get that to clear out.

As with @AdamCameron , I’d be curious to know more about what the Rasia client is trying to do.