In JAX-WS spec 4.2.1 is says "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." This could imply that if I do change the request property it should be applied to all future invocations using the same proxy instance.
Also, from http://java.sun.com/javase/6/docs/api/javax/xml/ws/BindingProvider.html#getResponseContext() says about getResponseContext(): "Get the context that resulted from processing a response message. The returned context is for the most recently completed synchronous operation. Subsequent synchronous operation invocations overwrite the response context." This could indicate that in multiple thread scenario getResponseContext() could return information about any 'recently completed' call from any invocation using the same proxy instance. This is all a bit of a stretch but I'm just trying to understand what's the right approach from the spec point of view. But either way, whatever the solution I think this needs to be documented because each approach has its own issues. Jarek On 5/4/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
On Friday 04 May 2007 14:15, Jarek Gawor wrote: > I have noticed that the RequestContext and ResponseContext of > JaxWsClientProxy is associated with the thread and not the instance of > the proxy. My understanding is that it should be associated with the > instance but I can't find any specific documentation on this issue in > the specs. I was afraid this issue was going to come up. :-( Basically, there isn't a way to make the proxies thread safe without making them ThreadLocals. The main problem this causes is that one thread cannot configure a global proxy that is then used on other threads. The configuration is lost. The ResponseContext really needs to be ThreadLocal. It's the context information for the last request. If you have two threads making requests, if it wasn't local, you'd have no idea what the response correlated too. For the request, there are a few options: 1) Keep it thread local - this is thread safe, but has the config issues. 2) Have a "default" one that is used until the first invoke on a thread. It then gets copied to the ThreadLocal. 3) Make it non-local - this has other concurrency issues. Definitely something I'll need to noodle on a bit more to figure out all the ramifications of the various options. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
