In other words, different users accessing the server, with a different session for each one, could not share this application scope objects caches.
Right? Adolfo >From: "Adolfo Miguelez" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: session managed caches >Date: Sun, 05 May 2002 14:21:41 +0000 > >Thanks Craig, > >I agree with your reply for session scope caches. Containers are able to >serialize all java.io.Serializable session attributes and share them among >VM, if needed for different requests. They include these objects caches. > >However, in the Ted's article, it seems to extend this behaviour for >application, request and page scopes also: >TED: "The wrapper object can include a named "scope", a property to >indicate >whether the item is permanent or temporary, and a counter." > >As far as I understand, for page scope, is less than a problem. Developer >should not intend to access cache out of page scope, and therefore not >chance to swich VM for the same request. For request scope, the same >applies, since you do not intend to use the data further the request scope. >No possibility for a container balancing so far, within the same request. > >HOWEVER, for application scope, AFAIK, container will not guarantee that >response would be covered by same VM as the previous ones, since a load >balancing could happend. In such a case VM data, and therefore possible >objects caches, could not be accessible, is not it? And in Ted's article >seems to consider application scope as permanent scope. >Under this consideration of application scope, objects caches would not be >applicable. (Please, confirm). > >Sorry if I am messing up the point or if I missundertood or my previous >explanation was not acurate enought. > >Adolfo. > >>From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >>Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >>To: Struts Users Mailing List <[EMAIL PROTECTED]> >>Subject: Re: session managed caches >>Date: Sat, 4 May 2002 16:37:43 -0700 (PDT) >> >>In a clustered environment (i.e. when you mark your application >><distributable> in the deployment descriptor), both the container and the >>application have some additional requirements: >> >>* The container must guarantee that, at a given point in time, >> any requests for the same session must all be served from >> the same server. It is legal to migrate a session to a different >> server, but only "in between" requests. >> >>* The application must guarantee that, for all attributes it stores >> in the session, that the underlying classes correctly implement >> java.io.Serializable. That way, when the container wants to migrate >> your session from one server to another, it knows that all of the >> attributes can be moved as well. >> >>Thus, if you store a resource cache in the session, you must make sure >>that the collection class you use is Serializable (all of the standard >>Java collection classes are), *and* that all the things you cache there >>are themselves Serializable as well. If they are, then the container will >>take them along with your session if it decides to migrate from one server >>to another. >> >>Craig >> >> >> >>On Sat, 4 May 2002, Adolfo Miguelez wrote: >> >> > Date: Sat, 04 May 2002 22:28:12 +0000 >> > From: Adolfo Miguelez <[EMAIL PROTECTED]> >> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> >> > To: [EMAIL PROTECTED] >> > Subject: session managed caches >> > >> > >> > Hi All, Hi Ted, Hi Craig, >> > >> > I got the paragraf below from page at Ted Husted site: >> > >> > http://husted.com/about/scaffolding/catalog.htm >> > >> > "Provide session management for cached resources." >> > "Most Web applications require use of a workflow, and need to save >> > ActionForms and other attributes for future use. These items may also >>need >> > to be released in a block when the workflow completes. A convenient way >>to >> > handle this is to define a "Resource Cache". This can simply be a hash >>map >> > that uses a wrapper object to manage its items. The wrapper object can >> > include a named "scope", a property to indicate whether the item is >> > permanent or temporary, and a counter. To keep the cache manageable, a >> > threshold can be set, and the oldest temporary items removed when the >> > threshold is reached and a new item needs to be added." >> > >> > I asked this question to Craig previously and I got a response which I >> > agree. However, this paragraf make me get some doubts. >> > >> > As far as I understand, Ted suggest, the creation of caches of >>resources >>in >> > memory, managed by session. However, in clustered environments, memory >>would >> > be lost when VM is switched, so resources cache would be not >>accessible. >> > This would not happen if cache is held in session, because session >> > management in web containers. >> > >> > Sorry is this a repeated question, gratefully responsed by Craig but >> > paragraf takes me worried. Is it a mistake or just it suppose a single >> > server environment. Maybe I missuderstood. >> > >> > Regards, >> > >> > Adolfo >> > >> > >> > >> > _________________________________________________________________ >> > Join the world�s largest e-mail service with MSN Hotmail. >> > http://www.hotmail.com >> > >> > >> > -- >> > 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]> >> > > > > ><HTML> > <HEAD> > <TITLE>Adolfo's signature</TITLE> > </HEAD> > <BODY> > <center><b><em>Adolfo Rodriguez Miguelez</em><b></center> > > </BODY> > </HTML> > > > > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
