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