if I understand correctly, you have multiple tomcat instances. 1. each system has the same webapp 2. each system caches data locally 3. you want to update the application context 4. you want the cluster to replicate the application context 5. you didn't design it and have to live with it replicating the app context ideally should happen in a push manner if being "in sync" is of any importance. I'm not convinced enhancing the exist session replication is the best way to handle this because the data could be huge. Even if the documentation were to state, do not put large amounts of data in the application context, people will still do it and blame tomcat. the worse part is caching app context data means an additional burden on the session replication mechanism, which is dangerous. It might be better off for your app context to register for updates with a JMS server. this way, changes can be pushed to the tomcat instances. Or something equivalent to a push mechanism. peter lin
Rick Szeto <[EMAIL PROTECTED]> wrote: As I was not involved in the design decision, I can not say whether or not that it is a good call or not. But the reason that we need application context replication is that the entire site serves up relatively static data(infrequent updates) to all of it the users. They did not feel that hitting the DB every time a page is accessed was efficient. Rick --------------------------------- Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
