Sounds to me you simply need to create a POJO to contain the execution context state (and definitely not static variables beyond that to support the singleton pattern). You could most simply use a HashMap, but there is a stronger argument around semantics for creating a POJO to hold that state. Then, you simply expose an interface to the POJO common to both (all) execution environments.
>> However, "comet" is becoming more popular This is not so new as you might think. It was once called "server push". In any case, it sounds like you are writing applets requiring a persistent connection to the web server? Don't ever forget the true beauty of a well behaved POJO, especially those that are serializable (or if you must use XML because it is sexy to do so, just use XMLEncoder). Just send the bean across the wire and go stateless! It can travel both ways. So the applet sends the bean to the server, which returns any new state within the bean to the applet. Isn't that essentially what you do in a stand-alone.... passing beans around? -----Original Message----- From: tbee [mailto:t...@tbee.org] Sent: Tuesday, January 05, 2010 5:06 AM To: users@tomcat.apache.org Subject: Comet and thread binding I often use (abuse?) the fact that a single thread is used to completely handle a request, by binding objects to the thread. Not all code down the line of a request is aware that it is running inside a web server. I have utility classes that are used in standalone applications and web application, business models that are used in both, etc. So I cannot rely on either environment being present. Furthermore I do not like passing a context (being it a request, or whatever) all the way down an execution path. So, in a standalone (swing) application I use static variables to hold certain instances, and within web applications these instances are placed in the session or application context. In order to make access to these instance uniform, I bind them to the current thread. This works fine; only when you start spawning worker threads, you need to make sure to copy the references, but it is uniform for both environments. However, "comet" is becoming more popular and this technique may suspend a request and freeing up the thread for reuse. This means the request may be resumed in another thread, which will screw up my bindings. So I'm losing my thread as a stable denominator... Is there anything that can uniquely identify a execution context; so in a webapp that would be the request and in a stand alone that would be a singleton. -- View this message in context: http://old.nabble.com/Comet-and-thread-binding-tp27026574p27026574.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
