cp.org/en/jsr/detail?id=315)
--
View this message in context:
http://old.nabble.com/Comet-and-thread-binding-tp27026574p27057207.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail:
--- On Thu, 1/7/10 at 12:02 AM, tbee wrote:
>
> Yes. But the problem with comet is that it may switch
> threads "mid request";
> a request can be suspended, the thread freed up, and after
> a while the
> request is resumed, but by probably a different thread. So
> I cannot bind the
> request t
o I cannot bind the
request to the thread anymore.
--
View this message in context:
http://old.nabble.com/Comet-and-thread-binding-tp27026574p27056330.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubsc
--- On Wed, 1/6/10 at 10:18 PM, tbee wrote:
>
> The issue is not the storage, but access to the storage.
> How would I, at any
> place in the execution, access it, without passing the
> context to each
> method.
Have you considered using ThreadLocal?
- Bob
-
s message in context:
http://old.nabble.com/Comet-and-thread-binding-tp27026574p27055509.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For a
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
nominator... 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
