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.
Vishy, what do you think?
Kief
