cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 310026124542-0...@t-online.de (Mark Washeim)
Subject Re: cooperative session handling (was: Dynamic XML generation)
Date Thu, 20 Jul 2000 20:19:22 GMT
on 20/7/00 9:49 pm, Uli Mayring at ulim@denic.de wrote:

> On Thu, 20 Jul 2000, Jeremy Quinn wrote:
> 
>> so your taglib could do something like this:
>> 
>> if there a session?
>> if it contains my auth.stuff?
>> go for it
>> else
>> login
>> else
>> make one
> 
> Yeah, that's what I'm doing with the only difference that I care about
> invalidating sessions. More below.
> 
>> When you want to log a user out, you remove your auth:stuff from the
>> Session, and only invalidate the session if it contains nothing else. In
>> fact due to the multithreaded nature of the Beast, it would probably be
>> safer never to invalidate a session, in case something else was about to
>> use it.
> 
> What's the session.invalidate() method for, then? Sorry if I sound dumb,
> but I believe Sun doesn't implement random methods for fun and profits. It
> would be much, much easier for me to implement auth: if I didn't have to
> worry about invalidating sessions. So I am really not reluctant to take
> your advice, it just "feels bad" not to clean up :)
> 
>> Reading the Servlet Spec ....
>> Sessions should be automatically invalidated by the server or Servlet
>> engine, there should be a setting for "session persistence" in your engine.
>> Servers can offload active sessions to file if memory gets constrained.
> 
> Yeah, the session times out after one hour in my case, so you
> theoretically can have the user surfing unprotected pages for one hour and
> the servlet engine keeps the session needlessly. Is this overhead
> negligible?
> 
> Ulrich


Just my two bits. 

In most cases where any significant number of applications are running,
namely, most public websites running servlets, there is rarely a need for
any individual servlet to invalidate the session.

In fact, there is more overhead in the creation of session objects than
called for.

Our application framework hides the session from individual servlets and
'pools' the session objects, as it were. We found that running dozens of
servlets for any given client required the session practically persistantly
and so, added a facade to it...

The facade ensures unique identity for names of keys by prefixing the
servlet class name.

Just my thoughts....

-- 
Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell

 



Mime
View raw message