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]>
