Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@www.apache.org Received: (qmail 62203 invoked from network); 12 Jul 2004 11:54:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 12 Jul 2004 11:54:44 -0000 Received: (qmail 87185 invoked by uid 500); 12 Jul 2004 11:54:36 -0000 Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 87107 invoked by uid 500); 12 Jul 2004 11:54:35 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 87069 invoked by uid 99); 12 Jul 2004 11:54:35 -0000 X-ASF-Spam-Status: No, hits=0.6 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.27.1) with SMTP; Mon, 12 Jul 2004 04:54:34 -0700 Received: (qmail 4765 invoked by uid 50); 12 Jul 2004 11:55:55 -0000 Date: 12 Jul 2004 11:55:55 -0000 Message-ID: <20040712115555.4764.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 30028] - session attributes Map may become inconsistent start causing "strange" problems X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30028 session attributes Map may become inconsistent start causing "strange" problems ------- Additional Comments From vlad@jstripe.com 2004-07-12 11:55 ------- Tim, "The spec says the session sync is responsibility of the developer." i think that you are ignoring the fact that the spec is ambiguous about syncing session access. Moreover the spec is saying about "session resources". Given that the sync problem is *easy* to rectify on the container side with no side effects it is a reasonable thing to do. I dont mind calling it an enhancement either. Cluster problem you described is a different matter. If you use "sticky" load balancing you wouldnt have experienced that. Vlad --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org