tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <christopher.d.schu...@comcast.net>
Subject Re: Session vs. Application Replication
Date Thu, 30 Oct 2003 13:34:28 GMT
All,

> 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: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message