RE: RES: Objects In Session
Hi Craig, What about using database session state caching (see http://martinfowler.com/isa/databaseSessionState.html) Oracle too, in his Oracle 9iAS Best Practices White Paper, posted last week on OTN, suggests considering database session state (BP- SESSIONS-1: PERSIST SESSION STATE IF APPROPRIATE). Giustino De Vincentiis -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 9:14 PM To: Struts Users Mailing List Subject: Re: RES: Objects In Session On Wed, 17 Jul 2002, julio wrote: Date: Wed, 17 Jul 2002 16:08:34 -0300 From: julio [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RES: Objects In Session Hi Craig, How do you solve this problem for your site(like yahoo) with 1000 users?? * Save anything I need in hidden variables that are resubmitted with the form, so I can still use request scope form beans. That way the info is effectively cached in the browser, instead of the server. (This is the biggest payoff, and the primary one that app developers have much control over.) * Reduce the amount of stuff that must be cached to an absolute minimum, by not caching rarely used things (or things that don't affect performance visibly if you get them from the database every time). * For non-user-specific data, do your caching separately from the session, so that the same cached instance data can be reused. * Improve performance of my database server so that session caching becomes less important. * Buy more web server memory and/or more web servers (i.e. distribute the application). Julio Cesar Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RES: Objects In Session
On Thu, 18 Jul 2002, DeVincentiis Giustino wrote: Date: Thu, 18 Jul 2002 11:31:35 +0200 From: DeVincentiis Giustino [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: RES: Objects In Session Hi Craig, What about using database session state caching (see http://martinfowler.com/isa/databaseSessionState.html) This article seems more concerned with the issues regarding a logical transaction that takes more than one HTTP request to complete -- you don't want to keep an actual database transaction open across requests. But a side effect of this approach will definitely help reduce memory occupancy if you don't cache the data in memory. You should also note that an app server could have built in facilities to swap active but idle sessions out to a database or other persistent storage mechanism, the same way that an operating system can swap out idle processes. It's worth checking the docs for your server to see what is available in this regard. Craig Oracle too, in his Oracle 9iAS Best Practices White Paper, posted last week on OTN, suggests considering database session state (BP- SESSIONS-1: PERSIST SESSION STATE IF APPROPRIATE). Giustino De Vincentiis -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 9:14 PM To: Struts Users Mailing List Subject: Re: RES: Objects In Session On Wed, 17 Jul 2002, julio wrote: Date: Wed, 17 Jul 2002 16:08:34 -0300 From: julio [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RES: Objects In Session Hi Craig, How do you solve this problem for your site(like yahoo) with 1000 users?? * Save anything I need in hidden variables that are resubmitted with the form, so I can still use request scope form beans. That way the info is effectively cached in the browser, instead of the server. (This is the biggest payoff, and the primary one that app developers have much control over.) * Reduce the amount of stuff that must be cached to an absolute minimum, by not caching rarely used things (or things that don't affect performance visibly if you get them from the database every time). * For non-user-specific data, do your caching separately from the session, so that the same cached instance data can be reused. * Improve performance of my database server so that session caching becomes less important. * Buy more web server memory and/or more web servers (i.e. distribute the application). Julio Cesar Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RES: Objects In Session
On Wed, 17 Jul 2002, julio wrote: Date: Wed, 17 Jul 2002 16:08:34 -0300 From: julio [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RES: Objects In Session Hi Craig, How do you solve this problem for your site(like yahoo) with 1000 users?? * Save anything I need in hidden variables that are resubmitted with the form, so I can still use request scope form beans. That way the info is effectively cached in the browser, instead of the server. (This is the biggest payoff, and the primary one that app developers have much control over.) * Reduce the amount of stuff that must be cached to an absolute minimum, by not caching rarely used things (or things that don't affect performance visibly if you get them from the database every time). * For non-user-specific data, do your caching separately from the session, so that the same cached instance data can be reused. * Improve performance of my database server so that session caching becomes less important. * Buy more web server memory and/or more web servers (i.e. distribute the application). Julio Cesar Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
