[
https://issues.apache.org/jira/browse/CXF-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565384#action_12565384
]
Daniel Kulp commented on CXF-1410:
----------------------------------
But issue #2 is important as it is a spec compliance issue. If a client is
injected into a service running in some sort of app server, you have no control
over what threads are going to be using it. Configuration set on one thread
needs to be available for all uses of that proxy in the future no matter what
thread it's on.
In thinking about this some more, I really don't think there is ANY way to
overload the getRequestContext() stuff to accomplish this. For every solution
I can think of, I can find scenarios where it falls apart.
Thus, I'm going to suggest we create a new "ThreadSafeContext" interface with a
new getThreadRequestContext() (which would be completely separate from the
normal RequestContext) and add that to the proxies. If the user wants the out
of spec, but safe proxies, they would need to explicitely cast it down to that.
> Allow thread safe access to proxy with requestContext usage..
> -------------------------------------------------------------
>
> Key: CXF-1410
> URL: https://issues.apache.org/jira/browse/CXF-1410
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
> Affects Versions: 2.0.4
> Reporter: Gary Tully
> Priority: Minor
> Attachments: mt_context.patch
>
>
> It should be possible to cache a proxy and provide thread safe access to it.
> For example, the following code should work from multiple threads with
> deterministic results:
> Greeter greeter = // get cached proxy
> InvocationHandler handler = Proxy.getInvocationHandler(greeter);
> Map<String, Object> requestContext =
> ((BindingProvider)handler).getRequestContext();
> String threadSpecificaddress = // ...
> requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
> threadSpecificaddress);
> the proposal is to implement thread local request contexts and manage the
> mapping from shared proxy request contexts to the thread local.The
> synchronization point is on a call to getRequestContext. the return is a
> snapshot of the current shared proxy request context map.
> The map is such that it will echo modifications into the shared map. But
> further modifications to teh shared map will not be visible to the calling
> thread until subsequent getRequestContext call is made.
> In other words, an invoke works with a copy of the thread local context which
> takes into account modifications to the shared context at the time of the
> getRequestContextCall()
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
