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
