tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/session
Date Mon, 10 Jan 2000 18:21:00 GMT wrote:
> > > HttpSession createSession(Context ctx) {
> > >   int timeout=ctx.getSessionTimeout();
> > >  ...
> > > }
> > >
> >
> > Requires the session manager to be aware of Tomcat core internals (i.e. the method
signatures supported by
> > Context) instead of being a stand-alone black box.  Instead, the context should
configure the default
> > session timeout when it instantiates a particular Manager implementation.
> Context is the representation of a web application, and contains all the parameters in
> SessionTimeout is a property of a web application, and a servlet session manager should
> aware of the properties of a web application.
> ( it may make decissions based on other properties besides timeout and distributable,
> context path - for example to construct table names).
> In general, I think it's a bad ideea to have 2 places where web.xml properties are stored,
> i.e. once in Context and once in SessionManager.

Why store the timeout value in the Context at all? It's only used by the Manager so
it can go straight from web.xml to the Manager, during initialization as well as
in-service updates (the day such management functions are added).

> > > That also means you set the timeout for each HttpSession, so a management
> > > interface can change Context's properties and all following sessions will use
> > > the new value.
> > >
> >
> > The setTimeout() method implemented in your Context need merely forward the setting
on to the associated
> > Manager.  In fact, you probably call this very same method during the configuration
stage, so it's no extra
> > code.
> Yes, but that means you can't use a Manager for 2 contexts. The manager duplicates the
Contexts' timeout
> property.
> That is itself a problem - I don't think it's a good design to store the timeout property
in 2 places,
> and keep them in sync, but that's not as important ( we can remove get/setTimeout from
> and use getManager() instead).

I guess you say the same thing as I do above here?

> > > I strongly disagree ( -2 :-) on adding Manager in its current form, I think
> > > requirement to have on session Manager for each context is artificial and
> > > see no value on it.
> >
> > Instead, you find yourself having to pass a Context argument in every single method
call.  That seems
> > arguably less efficient -- quite aside from the encapsulation considerations which
motivated the original
> > design.
> I don't see why it's "less efficient" - the context is required in both cases ( in your
> you need it to get the Manager associaged with the context ).
> Passing 2 arguments instead of 1 is not "arguably less efficient" !
> I still don't know what "encapsulation consideration" you have in mind in this case.

Okay, I guess it's a matter of preferense, but since each context can have
different session management properties (such as timeouts, persistence, etc), having
a unique Manager for each context (instead of sharing one between contexts) is a better
approach IMHO.

Hans Bergsten
Gefion Software

View raw message