On Wed, 8 Aug 2001, Kief Morris wrote:

> Jim Seach typed the following on 04:29 PM 8/7/2001 -0700
> >> Selected setXXX methods in StandardSession will set the dirty bit to
> >> true indicating that Session data has changed and it needs to be
> >> saved
> >> in the next save cycle by PersistentManager.
> >
> >But what happens if in one servlet you put an object in the session,
> >then later, after the session has been saved, another request is
> >handled by a different servlet that get's the object from the session
> >and changes its state.
> >
> >In this case, you have to have the cooperation of the application
> >developer to call setDirty(true) so you know something has changed.  
> 
> This doesn't seem like a good idea - not only is it prone to developer
> error as you said, it also makes any application which uses it non-portable
> to other servlet containers.
> 
> 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. Maybe it's possible
> to use reflection to detect if an object has been modified? I've seen a DB
> persistence package which appears to do this, although I haven't examined
> that part of the code (ObjectBridge, aka OJB, on sourceforge).
> 

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.

I don't believe there is any general mechanism that a container can use to
tell whether the internal state of an application object has changed in a
way that is significant to the application.  The setAttribute() rule would
seem to be a reasonable alternative, because it lets the application tell
the container about changes - in a way that doesn't require servlet API
changes.


> Kief
> 

Craig


Reply via email to