On Thu, 9 Aug 2001, Kief Morris wrote:
> Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700
> >> Another possibility would be to flag the session is dirty when getAttribute()
> >> is called - it would result in unnecessary saves since it assumes the
> >attribute
> >> was modified even when it wasn't, but it would be safer.
> >
> >Someone has told me (haven't confirmed personally) that some app servers
> >treat a setAttribute() -- as opposed to getAttribute() -- as the signal to
> >set the internal "dirty" flag. The idea is that, if your application
> >modifies the internal state of an existing session attribute, then you
> >should call session.setAttribute() again to notify the container.
>
> Yes, flagging the session is dirty on setAttribute() makes sense. I was
> thinking that by also flagging it on getAttribute(), you're depending less
> on developers to take an extra step (calling setDirty() or making another
> call to setAttribute()). If an attribute is retrieved from the session, it may
> have been modified, so make the assumption that it was just to be safe.
> But this could erase a lot of the benefit of the dirty flag optimization, since
> writes are typically more common than reads.
>
> 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.
> Vishy, what do you think?
>
> Kief
>
>
Craig
