tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Morgan" <>
Subject RE: Comet and thread binding
Date Tue, 05 Jan 2010 13:20:29 GMT
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 [] 
Sent: Tuesday, January 05, 2010 5:06 AM
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
and web application, business models that are used in both, etc. So I
rely on either environment being present. Furthermore I do not like
a context (being it a request, or whatever) all the way down an

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;
when you start spawning worker threads, you need to make sure to copy
references, but it is uniform for both environments.

However, "comet" is becoming more popular and this technique may suspend
request and freeing up the thread for reuse. This means the request may
resumed in another thread, which will screw up my bindings.

So I'm losing my thread as a stable denominator... Is there anything
can uniquely identify a execution context; so in a webapp that would be
request and in a stand alone that would be a singleton.

View this message in context:
Sent from the Tomcat - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message