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