Robert.
On 3/22/24 14:11, Robert Turner wrote:
Thanks for figuring it out -- I will keep that in mind when I go to split
our "mega session object" up as that will impact some of the decisions for
sure.
Yeah, I guess you end up with a "dummy object" on the session as a result
-- I guess we got lucky with ours -- our handlers on the session object
call out to a "singleton" for tracking, so we probably never really thought
too much about it. So if you have an object on the session already, it pays
to just extend it and call out to the "singleton" instead (like we have).
Or, more likely, whoever implemented it discovered that you *must* have
a singleton for this kind of thing, and didn't just get lucky. :)
Some of the listener docs do often leave me wondering how exactly some of
them work (like who creates the object instance for this thing - like for
ServletContextListener).
The container does. It's in the spec :)
If you haven't read it, it's 100% worth reading and it's quite readable.
It was written by real humans trying to get a job done and not lawyers.
or whatever.
Although the one you quoted does seem to be
"clear enough" at least to me (not sure if your comments were sarcastic or
not).
Nope. I meant "I either didn't read this, or ignored what it said"
because there really is no confusion, there.
I'm not sure it's a good design though -- you would think session
listeners would be independent of the objects on the sessions. Hopefully
there was some logic behind the original design that isn't captured in the
code docs (well, I hope there was).
I can't know why the original design was the way that it was. Would be
interesting to be able to have an "observer" listener that doesn't have
to be put into each and every session? Possibly. But this isn't
particularly "expensive" to implement using the existing interfaces and
their existing semantics.
My guess is that sessionWillPassivate and sessionDidActivate are there
so that caches, connections to other systems, etc. can be re-created
after a session comes back into memory for things that aren't
appropriate to be Serializable. Maybe that's not appropriate for *every*
session and also if you put 10 caches into a session you just implement
each of your 10 re-creation algorithms separately.
If you had one uber-listener, it would have to understand how to
re-create all 10 of those caches and so the fine-grained notification
system is actually more flexible.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
