Thread-safety (or lack thereof) of Request/Response contexts

[Fred Dushin <fr...@dushin.net>]

Sorry, this is another naive JAX-WS question.

The CXF documentation at http://cwiki.apache.org/CXF20DOC/developing- 
a-consumer.html illustrates a pattern for implementing a CXF client.   
Under the section "Setting a request context" and "Reading a response  
context", the following code is presented:

{{{
// Set request context property.
java.util.Map<String, Object> requestContext =
   ((javax.xml.ws.BindingProvider)port).getRequestContext();
requestContext.put(ContextPropertyName, PropertyValue);

// Invoke an operation.
port.SomeOperation();

// Read response context property.
java.util.Map<String, Object> responseContext =
   ((javax.xml.ws.BindingProvider)port).getResponseContext();
PropertyType propValue = (PropertyType) responseContext.get 
(ContextPropertyName);
}}}

My question is, in a multi-threaded application, where say the client  
proxy (port, in the above example) is shared across threads, there  
are presumably no guarantees about the thread-safety of the use of  
the client-request or response objects, no?  Or are implementations  
free to "return" a context object out of thread-local storage, for  
example?  Does anyone know what the CXF behavior is here?

I guess what I need to know is, is the functionally correct way to  
use the above pattern to wrap it in a synchronized block (thus losing  
any scalability in the client)?  Or is the above pattern thread-safe  
(under the assumption that port may be shared across threads)?

Thanks!
-Fred

Re: Thread-safety (or lack thereof) of Request/Response contexts

[Willem Jiang <ni...@iona.com>]

Hi Fred,

I can't say the client proxy guarantees the thread-safety of use the 
request/ response contexts.
Because the request and response contexts are the no thread-local 
objects of the JaxWsClientProxy which implements the  BindingProvider 
interface.

I filled a Jira *CXF-470 
<https://issues.apache.org/jira/browse/CXF-470>* [1]  for it, and will 
make it thread-safe :).

[1] https://issues.apache.org/jira/browse/CXF-470

Cheers,

Willem.

Fred Dushin wrote:

>
> Sorry, this is another naive JAX-WS question.
>
> The CXF documentation at http://cwiki.apache.org/CXF20DOC/developing- 
> a-consumer.html illustrates a pattern for implementing a CXF client.   
> Under the section "Setting a request context" and "Reading a response  
> context", the following code is presented:
>
> {{{
> // Set request context property.
> java.util.Map<String, Object> requestContext =
>   ((javax.xml.ws.BindingProvider)port).getRequestContext();
> requestContext.put(ContextPropertyName, PropertyValue);
>
> // Invoke an operation.
> port.SomeOperation();
>
> // Read response context property.
> java.util.Map<String, Object> responseContext =
>   ((javax.xml.ws.BindingProvider)port).getResponseContext();
> PropertyType propValue = (PropertyType) responseContext.get 
> (ContextPropertyName);
> }}}
>
> My question is, in a multi-threaded application, where say the client  
> proxy (port, in the above example) is shared across threads, there  
> are presumably no guarantees about the thread-safety of the use of  
> the client-request or response objects, no?  Or are implementations  
> free to "return" a context object out of thread-local storage, for  
> example?  Does anyone know what the CXF behavior is here?
>
> I guess what I need to know is, is the functionally correct way to  
> use the above pattern to wrap it in a synchronized block (thus losing  
> any scalability in the client)?  Or is the above pattern thread-safe  
> (under the assumption that port may be shared across threads)?
>
> Thanks!
> -Fred
>