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