Scott Kurz wrote:
I thought it was useful to point out that was specifically a problem w/
a callback over binding.sca, as the proxy set up for a binding.ws
<http://binding.ws> (axis2) callback should be able to call back to the
right client today, right?
It shouldn't make any difference what the binding is. In all cases
the callback address is taken from the incoming message when the
proxy is created and injected, and this address is hard-wired into
the proxy. For a composite-scoped component, this will be the
callback address for whichever client did the first invocation on
the component, when the composite-scoped component implementation
instance was created. Subsequent invocations will not create and
reinject a new proxy.
Aside: there are two cases where it wouldn't be possible to create
a valid callback proxy at component instance creation time.
1) If the component has @EagerInit, it will be created at deployment
time when there is no incoming message from which to take a
callback address.
2) If the component offers a mixture of bidiectional services and
non-bidirectional services, and the invocation that creates
the component implementation instance is non-bidirectional,
there will be no callback address available when the component
implementation instance is created.
Reinjecting the proxy on every invocation might work if the
component is single-threaded, but not if it's multi-threaded.
Because of all these issues with making this work, it's easy to
see why OASIS decided to ban callback proxy injection into
composite-scoped components.
Simon
Scott
On Fri, Feb 6, 2009 at 12:55 PM, Raymond Feng <[email protected]
<mailto:[email protected]>> wrote:
Yes, the injected proxy for callback decides its target based on the
incoming invocation on the thread. For the concurrent access to the
composite-scoped component, synchronizations may be required for the
business logic but the callback proxy should be able to handle
different clients.
