I don't see that.
A single-valued reference would work the same way as a singleton
list. The content of the collection would be established at resolve/
connect time so the set of wires is known up front. The target
invoker then gets created at one of two points in time depending on
the scope relationship:
1) when the proxy is created
2) when the proxy is invoked
The first applies when explicit or implicit configuration marks the
wire as optimizable and/or eager initialized. The second applies when
there is a lazy association with the target.
In both cases though the proxy is connected to a single wire which is
connected to the target container which creates the target invoker;
no iteration should be needed.
--
Jeremy
On Feb 21, 2007, at 6:50 AM, Ignacio Silva-Lepe wrote:
What I meant by pre-processing is the kind that LocalTargetInvoker
performs by caching the invocation chain for the operation it cares
about.
If, in general, we have a list of wires for multiplicity *..n, then
this
could mean being able to work on each wire in the list at the time
the target invoker is created. If the target invoker's invoke
method is
hit with high frequency and it needs to go over the list of wires
every time, then it could slow down the invocation.
On 2/21/07, Jim Marino <[EMAIL PROTECTED]> wrote:
On Feb 21, 2007, at 5:08 AM, Ignacio Silva-Lepe wrote:
> Hi Jim,
>
> Yes, eliminating local composite services and references certainly
> eliminates the issue for them ... :-)
:-)
> And in general, getting the target invoker to point back at the
ser-
> vice/reference binding should also work even if it means that some
> pre-processing of the wire can't be safely performed at the
point the
> target invoker is created, which also means a certain level of
ineffi-
> ciency.
>
I don't think there should be any inefficiencies here. The
preprocessing will occur on the master node during the normalization
step. In the case of local bindings, since there will be no
LocalServiceBinding or LocalReferenceBinding any more, there won't be
any TargetInvoker subtypes for those; the only subtypes will be for
physical transports (e.g. CFX QPid, Axis, JMS, etc.) and component
implementation types.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
