Wouldn't this require synchronized blocks around all usage of request
contexts, if proxies were shared across thread instances? Would we
have to write code like:
{{{
// assume p is a reference to a proxy
synchronized (proxy) {
Map<String, Object> requestContext =
((BindingProvider)p).getRequestContext();
p.invoke(...);
}
Map<String, Object> responseContext =
((BindingProvider)p).getResponseContext();
}}}
I'm -1, if that's the case. (Not that I have a vote, or anything...)
-Fred
On May 14, 2007, at 11:03 AM, Jarek Gawor wrote:
Based on all the info we have on this issue I propose the following
change (patch attached). Basically, make the request context to be
associated with the instance and leave the response context as is
(associated with the thread).
What do people think?
Jarek
On 5/10/07, Jarek Gawor <[EMAIL PROTECTED]> wrote:
I talked to some Sun JAX-WS RI developers today at JavaOne and
although they were not 100% sure about this issue they were pretty
sure the request/response context properties are associated with the
proxy instance.
Jarek
On 5/5/07, Dan Diephouse <[EMAIL PROTECTED]> wrote:
> How does the RI do it?
> - Dan
>
> 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
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
