Cheers Craig,
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: Sun, 5 May 2002 15:00:17 -0700 (PDT) > > > >On Sun, 5 May 2002, Adolfo Miguelez wrote: > > > Date: Sun, 05 May 2002 14:21:41 +0000 > > From: Adolfo Miguelez <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Re: session managed caches > > > > 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). > > > >We've dealt with session scope in the previous discussion. Let's consider >the other scopes as well: > >* PAGE - for the purposes of this discussion, it's treated > exactly like request scope. Because you can't get to this > from an Action or Servlet anyway, it is not of much use > in a caching scenario. > >* REQUEST - Per section 4.10 of the servlet spec, the lifetime > of the requst object is the duration of the call to your > servlet's service() method, so the response is generated by > the same thread and JVM as the request. Containers that do > automatic failover may resubmit the request to another JVM, > but even there the complete request is processed in one thread > of one JVM. (But, it's not particularly useful for caching > purposes anyway -- the request attributes start out empty on > every request, so you'd have to go reconstruct the cache > every time. > >* APPLICATION - Per section 3.4.1, context attributes (which is where > you would cache anything) "are local to the VM in which they were > created. This prevents ServletContext attributes from being a shared > memory store in a distributed container." > > Some app servers might make additional promises about synchronizing > updates to servlet context attributes. That can be a very nice > feature (check the docs for your app server to understand what is > supported), but it's not portable. > >It's quite reasonable to cache read-only copies of information as servlet >context attributes (i.e. "in an application scope cache"). For example, >many apps load up commonly accessed stuff at application startup time, >even in a single-JVM environment, to reduce access time. If you run >multiple copies of the same webapp on different JVMs, every one of them >will have done exactly the same thing as they were started, so all the >cached data will be the same in all of them. > >The place you have to be careful, though, is if the data in your object >caches (stored in application scope) is changing -- there are no servlet >API level features that guarantee such changes will be propogated to other >JVMs (although your app server might do so). Indeed, the servlet spec >goes on, in section 3.4.1, to say "When information needs to be shared >between servlets running in a distributed environment, the information >should be placed into a session, stored in a database, or set in an EJB >component". > > > Sorry if I am messing up the point or if I missundertood or my previous > > explanation was not acurate enought. > > > >It would be well worth your time to peruse the relevant specifications >yourself, in order to determine what behavior is portable and what is not: > > http://java.sun.com/products/servlet/download.html > > > Adolfo. > > > >Craig > > > > >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]> > > > > > > >-- >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> _________________________________________________________________ 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]>
