--- "Filip Hanik (lists)" <[EMAIL PROTECTED]> wrote:
> From: "Filip Hanik \(lists\)" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Subject: RE: Clustering Application Scope Objects
> Date: Mon, 12 Apr 2004 09:49:41 -0500
> 
> and that is why we don't focus on implementing this, cause it not defined on
> how to resolve name/value pair conflicts if different servers set different
> values for the same name.
> If I were to implement this I would allow the user to have two ways of
> configure conflict resolution:
> 
> 1. set-is-set, meaning that if the attribute with a given name is set, it
> can not be overwritten
>    To set a new value, simply remove the old one, then set a new one.
> 
> 2. override, meaning that whenever a broad cast with a new value, the last
> value is set
>    To set a new value, just call context.setAttribute
> 
> Filip
> 
> -----Original Message-----
> From: Mike Duffy [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 11, 2004 10:53 PM
> To: Tomcat Users List; Struts Users Mailing List
> Subject: RE: Clustering Application Scope Objects
> 
> 
> >>>how would you solve conflicts?
> 
> For my purposes, I would let the database manage conflicts.  Each
> application scope object would
> be tied to the database, a change made on a specific application server
> would first update the
> database.  For example, the information from a table containing label/value
> pairs for product
> categories would be stored in application scope on each server at system
> startup.  If a change
> were made to the product categories, the change would first made to the
> database and then a change
> notification would be broadcast to all servers in the cluster, each server
> would then reload the
> information from the database.
> 
> In other cases, where application scoped objects are not backed by a
> database, the task of
> handling conflicts becomes more difficult.  I think you would almost need to
> create some sort of
> locking mechanism that does not allow changes to be made during an update.
> 
> Mike
> 
> 
> --- "Filip Hanik (lists)" <[EMAIL PROTECTED]> wrote:
> > not implemented right now, how would you solve conflicts?
> >
> >
> >
> > Filip
> >
> > -----Original Message-----
> > From: Mike Duffy [mailto:[EMAIL PROTECTED]
> > Sent: Friday, April 09, 2004 5:48 PM
> > To: Tomcat Users List
> > Subject: 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



        
                
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to