Bob Hall wrote:
>
> I don't have much Comet experience but given that it can pause and resume
> processing of a given request, would it be possible to bind your execution
> context to that 'request' and re-bind it to the 'new' Thread when request
> processing resumes?
>
That would be my quest
--- 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
Bob Hall wrote:
>
> Have you considered using ThreadLocal?
>
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
--- 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
-
Joseph Morgan-2 wrote:
>
> Sounds to me you simply need to create a POJO to contain the execution
> context state
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.
--
View this message
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. T
