cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: Request/ResponseContext of JaxWsClientProxy
Date Fri, 04 May 2007 20:13:58 GMT
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 <dkulp@apache.org> 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
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>

Mime
View raw message