Brian
I vote for storing information in session variables for the simple reason most Admins do not allow Browsers writing cookies on the hard drive for fear of introducing viruses to the system
+1 for session variables
Martin Gainty
From: "Brian McGovern" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: SessionState vs. request state.
Date: Wed, 9 Feb 2005 17:47:19 -0500
MIME-Version: 1.0
Received: from mail.apache.org ([209.237.227.199]) by MC6-F17.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Feb 2005 14:45:42 -0800
Received: (qmail 49425 invoked by uid 500); 9 Feb 2005 22:45:30 -0000
Received: (qmail 49412 invoked by uid 99); 9 Feb 2005 22:45:30 -0000
Received: pass (hermes.apache.org: local policy)
Received: from leni.reliaserve.com (HELO imediainc.com) (64.241.144.147) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 09 Feb 2005 14:45:30 -0800
X-Message-Info: JGTYoYF78jESkPxkwn2FXw4rMlcuUOy2In/RcGEKnAU=
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <mailto:[EMAIL PROTECTED]>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Post: <mailto:user@struts.apache.org>
List-Id: "Struts Users Mailing List" <user.struts.apache.org>
Delivered-To: mailing list user@struts.apache.org
X-ASF-Spam-Status: No, hits=0.1 required=10.0tests=FORGED_RCVD_HELO,HTML_50_60,HTML_MESSAGE
X-Spam-Check-By: apache.org
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SessionState vs. request state.
Thread-Index: AcUO+QeVnpJ3anHJRmmIRsAR1nyw2Q==
X-Virus-Checked: Checked
Return-Path: [EMAIL PROTECTED]
X-OriginalArrivalTime: 09 Feb 2005 22:45:42.0176 (UTC) FILETIME=[15968A00:01C50EF9]
Hi,
I'm planning my approach to a data driven app that I have to write in the near future. I've used struts before in more of a demo-type, proof of concept scenarios, and am no where near and expert, but now need to build a production level system.
For a web app that needed to display a username on every screen I was previously doing it like this:
HttpSession zCurrentSession = request.getSession(false); if (zCurrentSession == null){ zCurrentSession = request.getSession(true); } try { zUserInfoBn = zUserData.getUserInfo(sEmailAddress); zUserInfoBn.setIsLoggedIn(true); }catch (ApplicationException zAppEx){ throw zAppEx; //stubbed out not complete } zCurrentSession.setAttribute(sUSERINFO_BN, zUserInfoBn);
So I'm hoping I can get some opinions on how to display things like user information on the screens in an intelligent way. I'm not sure where the trade offs are between hitting the DB every time and storing at the request level, using cookies, or storing it some other way.
Any ideas would be helpful. I'm in the rare position of being able to take my time and think out the approach and would love input from people who've got more experience than me.
My env is linux, tomcat 5.0.28, latest jdk, struts, separate box running db (sql server 2000 w/ stored procs) on a 2.8ghz xeon box with 1 gig mem. To start the app shouldnt get more than 50,000 page views a month.
Thanks -Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]