Sharing data between servlets obviously depends on several things. If your servlets are within the same webapp, then the ServletContext is the most obvious choice to store the shared information, however, you will need to synchronize the data access and modification within the object. If you use the ServletContext, you don't have to worry about the Singleton pattern either.
If your servlets are in different webapps, then you can't count on anything, notably Singletons. Specifically, although it is commonly done, there is no guarantee that two different webapps are even running within the same JVM. But, more important is the differences in the classloaders between the two webapps. A class within Java is distinguished not only by name, but by its class loader. Mixing the class loaders into "common" areas can make a mess of things in a hurry, particularly with Singletons. So if you're trying to share information between disparate webapps, you really need to go outside the container. By "outside" the container, I mean some kind of external service, either a database, JNDI, EJB, RMI, JINI JavaSpaces, or something else you've created on your own. A very simple "outside" service is yet another webapp designed specifically to manage your shared information. By creating another servlet, you get all of the container provided management to start, stop, and remove the servlet "for free". The only real sticky wicket would be ensuring that your little state manager webapp starts up before the other webapps require its services. Also, you'll probably want to narrow who has access to this webapp to just the local webapps, or some other authentication mechanism. But, in the end, it all boils down to what kind of state you're sharing. Regards, Will Hartung -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
