You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mike Duffy <md...@yahoo.com> on 2004/04/10 21:48:07 UTC
[OT] Clustering Application Scope Objects
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?
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."
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.
I know that EJBs were designed to serve this purpose; however, I would like to bypass the overhead
and complexities of EJBs.
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?
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.
Mike
__________________________________
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
Re: [OT] Clustering Application Scope Objects
Posted by Curtis Taylor <c....@verizon.net>.
Hi Mike,
This is an interesting question. Using the PlugIn interface to store
"semi-static" data in the app context is a commonly accepted pattern (we use it
in the project I'm working on now). However, there's no mechanism currently
available in Struts to allow for data model change event notification
(evidently, that's the major difference between Struts & Barracuda, from what
little I understand of Barracuda). I'd personally love it if there were a simple
mechanism available to Struts for just such event notification.
In the meantime, you may want to store such data in session scope, as it's more
"volatile" (periodically speaking). I don't know the nature of your data, but if
it isn't a huge amount, it shouldn't be a problem.
Keep us posted on your progress.
Curtis
--
cee dot tee at verizon dot net
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Clustering Application Scope Objects
Posted by Matt Sgarlata <sg...@crystalcognition.com>.
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 <ja...@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
Re: [OT] Clustering Application Scope Objects
Posted by Mike Duffy <md...@yahoo.com>.
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 <ja...@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
Re: [OT] Clustering Application Scope Objects
Posted by Christian Bollmeyer <ja...@christianbollmeyer.de>.
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