> -----Original Message----- > From: Daniel Kulp [mailto:[email protected]] > Sent: Monday, August 29, 2011 8:36 AM > To: [email protected] > Cc: KARR, DAVID > Subject: Re: Is the "Request Context" essentially a ThreadLocal? > > 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.
Sigh. Ok. Just to be clear, does CXF manage to provide a thread-safety guarantee for the port, despite what the spec says?
