On Monday, August 29, 2011 2:03:37 PM KARR, DAVID wrote: > > -----Original Message----- > > From: Daniel Kulp [mailto:[email protected]] > > Sent: Monday, August 29, 2011 6:18 AM > > To: [email protected] > > Cc: KARR, DAVID > > Subject: Re: Is the "Request Context" essentially a ThreadLocal? > > > > On Saturday, August 27, 2011 1:01:21 AM KARR, DAVID wrote: > > > > -----Original Message----- > > > > From: KARR, DAVID (ATTSI) > > > > Sent: Friday, August 26, 2011 2:19 PM > > > > To: [email protected] > > > > Subject: Is the "Request Context" essentially a ThreadLocal? > > > > > > > > I consider this mostly a rhetorical question, but I need to ask > > > > it > > > > nevertheless. > > > > > > > > If your thread has a Port object, and you get the request > > > > context > > > > from > > > > > > that, and you have another thread referencing the same Port > > > > object, > > > > and > > > > > > it gets the request context, are those two request contexts > > > > always > > > > going to be different objects that don't conflict with each > > > > other? > > > > > > > > Whatever the answer, is this answer specific to CXF, or would > > > > any > > > > reasonable JAX-WS implementation do it effectively the same way? > > > > > > For some more background to this, I find the following statement in > > > > the > > > > > JAX-WS specification in section 4.2.1, "Configuration": > > > > > > "Modifications to the request context while previously invoked > > > operations are in-progress MUST NOT affect the contents of the > > > > message > > > > > context for the previously invoked operations." > > > > > > I also notice that CXF's "BindingProviderImpl" defines > > > > "requestContext" as > > > > "java.lang.ThreadLocal<java.util.Map<java.lang.String,java.lang.Object> > > > > >". > > > > You must be using a fairly old version of CXF. Hasn't been that way > > for a > > long time. :-) > > > > > So, it's obvious that CXF has done the reasonable thing, but what > > > > does that > > > > > statement in the spec really mean? Is that referring to something > > > unrelated? Is what CXF is doing indicated as a MUST or even a > > > SHOULD > > > > in > > > > > the spec? I'm not going to claim that what CXF is doing isn't a > > > good > > > thing, I just want to understand whether I should expect OTHER > > > implementations to do the same thing, and because the spec says so. > > > > By default, CXF treats the response context as a ThreadLocal. > > However, for > > spec compliance, the default for the request context is "per proxy". > > Part of > > this is due to injection and configuration requirements of the spec. > > Basically, the app server needs to be able to create the client on any > > thread, > > configure it by setting values in the request context, and inject that > > into > > the app and have those values be "set" for us by that proxy on any > > thread. > > Also per spec, if any values are set into the proxy, all other threads > > should > > see it. > > > > However, we decided that's kind of bogus so we added the ability to > > flip it to > > a thread local request context as well. Setting that, however, will > > result > > in non-portable behavior. > > Interesting. I assume that "proxy" is the same as "port"?
Yea. > So, if we were being spec-compliant, then we should not use the request > context for anything that actually varies by each request? I suppose if we > really had to, we could do something bizarre like put in a map keyed by > thread id and had a handler pull it off? Well, I guess the right answer really is that you should not use a single port to issue concurrent requests if you want to be spec compliant. Either create a port per thread, use a pool of them, or synchronize on one so that the port is only ever issuing a single request at any given time. The spec does NOT provide any guarantees of thread safety of a port/proxy. An implementation may or may not be thread safe to use that way. If you want portable code, do not assume the port is thread safe at all. -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
