Sorry for the late reply, but anyway....
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: 10 August 2001 16:31
> To: [EMAIL PROTECTED]
> 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
>
>
