cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-1410) Allow thread safe access to proxy with requestContext usage..
Date Mon, 04 Feb 2008 14:37:08 GMT

    [ 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.


Mime
View raw message