Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Reply-To: <rokicki@instantis.com>
From: "Tomas Rokicki" <rokicki@instantis.com>
To: <tomcat-dev@jakarta.apache.org>
Subject: RE: Addition of 'dirty' field to Session interface
Date: Wed, 8 Aug 2001 13:03:22 -0700
Message-ID: <NDBBIAKJOKMCIMCFAIDEKEIHKAAA.rokicki@instantis.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <4.3.2.7.2.20010808222945.02f05168@pop3.demon.co.uk>

Best to do this by layering your own abstraction on top of Sessions.
That's what we do [although we don't use it to solve this particular
problem].

-tom
-----Original Message-----
From: Kief Morris [mailto:kief@bitbull.com]
Sent: Wednesday, August 08, 2001 12:36 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: Addition of 'dirty' field to Session interface


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).

Kief