Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 82693 invoked by uid 500); 10 Aug 2001 14:17:33 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 82679 invoked from network); 10 Aug 2001 14:17:33 -0000 Message-Id: <4.3.2.7.2.20010810165402.0343aaf8@pop3.demon.co.uk> X-Sender: kief_bitbull@kief.demon.co.uk@pop3.demon.co.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Aug 2001 17:03:31 +0300 To: tomcat-dev@jakarta.apache.org From: Kief Morris Subject: Re: Addition of 'dirty' field to Session interface In-Reply-To: References: <4.3.2.7.2.20010809215959.029f1550@pop3.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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