I agree with this inquiry. I think replication of application context attributes is conceptually as necessary as session replication. I usually store things like connection information to back-end servers, counters and other stuff that I need to share among all sessions.
I'm sorry, but I think this discussion is really very silly. If you have your application set up to load some stuff into the application (context) scope on startup, then if you start it up in different places, all the context scopes tshould look the same! There's no need to replicate context state between servers running the same application.
If I need to dinamically modify any of these data, I would like it to be modified in all cluster nodes.
Now this is the first question in the thread that makes any sense at all to me. Sure, if you want to update something and send it to all of the servers in a cluster, you might want to do something like this.
Here's my answer: Use a shared JNDI resource and leave this dynamic stuff out of the context scope. Any decent clustering enterprise container will let you deploy something into the JNDI tree of a running cluster.
Even if you're using a server that doesn't do something like this (like Tomcat, I think), you should be able to write a small servlet/JSP that is capable of inserting your new resource into the JNDI tree.
If you absolutely *have* to store your stuff in the context scope, and you absolutely *cannot* use JNDI, then write your own tool. Here's how it would work:
1. Everything in the context should be serializable.
2. Write a servlet that can handle a client request to "send" resources to other machines. Either provide URLs to the services on the remote machines, or store those URLs in a database or whatever.
3. With clever use of ServletContext.getAttributeNames and/or ServletContext.getAttribute, obtain all of those resources you wise to send to the other servers.
4. Put all the name/value pairs into a Map implementation.
5. For each remote machine you have, open a URLConnection to each one and dump the map of resources into the OutputStream wrapped up in an ObjectOutputStream.
Good luck handling the restoration of any transient state that's related to any of the resources themselves.
Can we please stop talking about this, now?
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
