tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbee <t...@tbee.org>
Subject Comet and thread binding
Date Tue, 05 Jan 2010 11:05:58 GMT

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


Mime
View raw message