tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Addition of 'dirty' field to Session interface
Date Fri, 10 Aug 2001 15:31:06 GMT


On Fri, 10 Aug 2001, Kief Morris wrote:

> Craig R. McClanahan typed the following on 12:40 PM 8/9/2001 -0700
> >> Now that I think about it though, any time a session is used in a request, 
> >its 
> >> lastAccessedTime will be updated, so the session must be considered dirty.
> >> So worrying about tracking attributes isn't necessary: the session only needs
> >> to be flagged dirty when it is retrieved. Tracking the dirty status is 
> >still a good 
> >> optimization, since it ensures sessions aren't saved multiple times between

> >> requests, or after requests which never access the session.
> >> 
> >
> >If I knew that the access time had been updated but not any attributes, I
> >could probably distribute that information pretty cheaply (without having
> >to serialize and deserialize the attributes as well).  Thus, it's probably
> >worth distinguishing between the two cases.
> 
> But we're still stuck with trusting the user to signal that they've modified
> an attribute, which I'm not comfortable with. Asking them to call setAttribute()
> is fairly clean, portability wise, but we would be guaranteed to get a perpetual
> stream of developers missing that bit of the docs and asking why Catalina
> sometimes loses their session data across restarts. Plus people might use
> 3rd party code which doesn't conform to this Catalina-specific requirement.
> 
> I think my suggestion of flagging any attribute retrieved with getAttribute() 
> as dirty should guarantee modified attributes are always saved, although these
> would be unnecessarily saved if the attributes are only read. My opinion is
> that guaranteeing correctness without relying on developers following a
> non-standard technique is worth the trade-off.
> 
> Kief
> 
> 

Sounds like a policy decision we should leave in the hands of whoever
deploys the application (i.e. a configuration switch :-).

Craig



Mime
View raw message