[
https://issues.apache.org/jira/browse/CXF-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579517#action_12579517
]
Daniel Kulp commented on CXF-1410:
----------------------------------
I'm implementing this as follows:
By default, the requestContext is "spec/tck" compliant and is not thread safe.
The call to getRequestContext() just returns the underlying shared map.
However, if you set "thread.local.request.context" property (either via the
properties in the jaxws:client spring config or just in the
getRequestContext()) to Boolean.TRUE or "true", then subsequent calls to
getRequestContext() will return a ThreadLocal version. The FIRST time
getRequestContext() is called on the thread is the only time the values are
copied from the shared into that threads. (however, sets are pushed back into
the shared).
This simplifies things a bit. Since the configuration is explicit, we don't
need to try and do the reload stuff.
> 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
> Assignee: Daniel Kulp
> Priority: Minor
> Fix For: 2.1
>
> 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.
