RE: Comet and thread binding
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 question exactly :-) There probably would a "suspend" and "resume" listener for then the threads are suspended and resumed in a comet scenario, but it has to be standarized. I see there is something defined in Servlet 3.0 (JSR 315, http://jcp.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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Comet and thread binding
--- 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 to the thread anymore. 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? - Bob - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Comet and thread binding
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 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Comet and thread binding
--- 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Comet and thread binding
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 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 additional commands, e-mail: users-h...@tomcat.apache.org
RE: Comet and thread binding
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
