struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@crystalcognition.com>
Subject Re: [OT] Clustering Application Scope Objects
Date Sun, 11 Apr 2004 03:16:40 GMT
Hi Mike,

Your JMS approach sounds fairly sophisticated; could take a while to 
implement ;-)

Hibernate provides some out-of-the-box cacheing implementations, some of 
which take on this problem.  I think you'll find this portion of their 
user guide fairly relevant:

http://www.hibernate.org/hib_docs/reference/html_single/#performance-s3

In particular, the SwarmCache and JBoss TreeCache look like they could 
do what you're looking for.  I bet they could be used outside Hibernate 
too, but I'm not sure.

Matt

Mike Duffy wrote:

>Thanks Christian,
>
>Let me give you a specific example of what I am trying to do.
>
>I have several different sets of label/value pairs that are stored in database tables.
 These
>label/value pairs make up the select options and other interface options for web pages
in the
>application.  The options do not change that often, so rather than going back to the database
each
>time a page is displayed, I'd like to store the options in maps that are stored in application
>scope and easily accessible through JSTL.
>
>On the occasion that the options do change, I'd like to reload the applicable maps to
all servers
>in the cluster.  
>
>It seems like this would be a good feature for Tomcat to have, but from reading the documentation
>it seems that the feature is not there.
>
>Perhaps some sort of JMS broadcast service would do the trick.  Does any one have any
suggestions?
>
>Mike
>
>
>--- Christian Bollmeyer <java@christianbollmeyer.de> wrote:
>  
>
>>On Saturday 10 April 2004 21:48, Mike Duffy wrote:
>>
>>Hi,
>>
>>    
>>
>>>I've read documentation for The Tomcat 5 Servlet/JSP Container:
>>>Clustering/Session Replication HOW-TO
>>>http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.html
>>>
>>>I understand clustering for individual user sessions.  Are there any
>>>correlated methods for clustering application scope objects?
>>>      
>>>
>>AFAIK there's nothing in the Servlet API specifications in this
>>direction. Sessions may be swapped in and out by several
>>different means (serialization or database), but application
>>scope information is kept individually for each JVM.
>>
>>    
>>
>>>The J2EE API for the Interface ServletContext states, "In the case of
>>>a web application marked "distributed" in its deployment descriptor,
>>>there will be one context instance for each virtual machine. In this
>>>situation, the context cannot be used as a location to share global
>>>information (because the information won't be truly global). Use an
>>>external resource like a database instead."
>>>      
>>>
>>Yes. But then, it makes no difference whether your application
>>is marked as 'distributable' or not when considering application
>>scope objects. Application scope is always limited to a single
>>JVM. 'Distributed' is about sessions only.
>>
>>    
>>
>>>Rather than use a database, what I would like to be able to do is
>>>make a call to
>>>
>>>    servlet.getServletContext().setAttribute(key, object);
>>>
>>>and have the object stored in the application scope of all servers in
>>>the cluster.
>>>      
>>>
>>That surely would be desirable, but I don't know of any
>>'official', declarative means to achieve such behavior.
>>Then: automatically synchronizing application scopes
>>between several JVM instances would cause a lot of
>>additional synchronization troubles - who determines
>>what's the actual system state at a given point, e.g.
>>if you update an application scope object (that is
>>globally shared) on one server, and another user
>>does likewise on a second one, what should be
>>the end result? And so on.
>>
>>    
>>
>>>I know that EJBs were designed to serve this purpose; however, I
>>>would like to bypass the overhead and complexities of EJBs.
>>>      
>>>
>>EJBs live in the backend and are independant from
>>the web tier. Looking at the problem from a 
>>web tier view (which is what Struts is about),
>>it should not make any difference whether the
>>information comes directly from a database
>>in the end or from an EJB tier in-between.
>>That's transparent. Anyway, using EJBs
>>won't solve your problem in the end, for
>>it's an entirely web tier specific issue,
>>and EJBs are not part of that.   
>>
>>    
>>
>>>If there isn't a switch that can be flipped in Tomcat, there might be
>>>a way to create a lightweight JMS administration class to serve this
>>>purpose.  Has anyone tried this?
>>>      
>>>
>>There is no switch (remember the spoon
>>boy in Matrix I ? :-). But the JMS idea is
>>interesting. Never actually tried it, but
>>of course, you can always handle
>>application specific logic programma-
>>tically, including using JMS for updating
>>application scopes in a distributed 
>>environment. But I never tried.
>>
>>    
>>
>>>If the answer to this question is RTFM, please send a link; I've
>>>looked through the documentation and I can't seem to find a clear
>>>reference.
>>>
>>>Thanks for your time and consideration.
>>>      
>>>
>>Just some thoughts that came to me
>>on early Easter Sunday :-) Let's better
>>say: night; it's 2:16 local time here. So
>>I should better go to bed.
>>
>>    
>>
>>>Mike
>>>      
>>>
>>HTH,
>>-- Chris.
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>    
>>
>
>
>	
>		
>__________________________________
>Do you Yahoo!?
>Yahoo! Small Business $15K Web Design Giveaway 
>http://promotions.yahoo.com/design_giveaway/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message