tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reilly, John" <John.Rei...@xelector.com>
Subject RE: Addition of 'dirty' field to Session interface
Date Fri, 24 Aug 2001 16:54:32 GMT
Sorry for the late reply, but anyway....

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: 10 August 2001 16:31
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Addition of 'dirty' field to Session interface
> 
> 
> 
> 
> 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 :-).

This could cause a lot of headaches answering user questions.  Once
getAttribute is called it must be assumed dirty until the service method (or
goGet, etc.) has completed.  As far as I can see there is still the
possiblity of a thread updating fields of attribute object in which case the
session must be assumed dirty at all times.   Also, I don't think its a good
thing for the developer to have to indicate that a session is dirty.

jr

> 
> Craig
> 
> 

Mime
View raw message