[
https://issues.apache.org/jira/browse/CXF-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565368#action_12565368
]
Gary Tully commented on CXF-1410:
---------------------------------
On issue 1, if the thread local contexts are null, not the empty hash map, then
the proxy contexts should be used for a request. If the local contexts is an
empty map then getRequestContexts has been called and the empty context list
may be the result of a thread removing all of the values from the local
contexts so the local contexts are good.
The problem I had that caused an invoke to just use the thread local contexts
was the case of a remove() operation on the context. If another thread does a
put, the calling context should not see it.
So I think the case of a local thread context not being initialised is a
special case where the shared/proxy contexts are still relevant.
on issue 2, this is by design, the sync point is on a call to
getRequestContexts.
> 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.
