Raymond Feng wrote:
Thanks for the quick response. I agree with the points you are making. A
few more arguments:
1) In many cases, the service method produces a DTO and it either
doesn't retain a reference to the return value or it won't mutate it
after the call. It's not wise to copy the DTO.
>
If the service doesn't retain a reference to the DTO, it can assert
@AllowsPassByReference. If it does retain a reference but never modifies
it (are you 100% sure? what will happen when the next programmer updates
the code? never say never! what about other code that might get the
reference and modify it? does the reference really need to be retained?)
then the service could assert @AllowsPassByReference even though it
doesn't strictly meet the conditions.
2) If the client side modifies the input data in a different thread
after issuing a call to the service, the PBV may get the wrong snapshot
of the parameters too.
>
That's one of the conditions that disqualifies the client from asserting
@AllowsPassByReference. See section 2.3.2.
3) For remotable invocations, a typical client sends out a list of DTOs
for service invocations, and get a new DTO back. The DTO design usually
implies immutable data (even not explicitly enforced in the programming
language such as Java).
For DTOs passed from client to service:
If the client will "never" modify these objects after sending them,
it can assert @AllowsPassByReference. If the service will "never" modify
these objects after receiving them, it can assert @AllowsPassByReference.
For DTOs returned from service to client:
If the service will "never" modify these objects after returning them,
it can assert @AllowsPassByReference (point 1 above). The client can
also assert @AllowsPassByReference as the criteria for this don't say
anything about returned values.
Simon
Thanks,
Raymond
/________________________________________________________________
Raymond Feng
rf...@apache.org <mailto:rf...@apache.org>
/Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com
/
________________________________________________________________/
On Feb 7, 2011, at 4:03 PM, Simon Nash wrote:
Raymond Feng wrote:
Hi,
I added the support for AllowsByReference for the references as well
as the implementation classes/methods based on the spec. Now I have
some questions for the SCA spec (Ideally I should bring these
questions to the SCA spec group but I don't have OASIS membership).
The following is quoted from the SCA spec:
The @AllowsPassByReference annotation allows service method
implementations and client references to be marked as “allows pass by
reference” to indicate that they use input parameters, return values
and exceptions in a manner that allows the SCA runtime to avoid the
cost of copying mutable objects when a remotable service is called
locally within the same JVM.
230 *2.3.4 Using “allows pass by reference” to Optimize Remotable Calls*
231 The SCA runtime MAY use by-reference semantics when passing input
parameters, return values or
232 exceptions on calls to remotable services within the same JVM if
both the service method implementation
233 and the service proxy used by the client are marked “allows pass
by reference”. [JCA20009]
234 The SCA runtime MUST use by-value semantics when passing input
parameters, return values and
235 exceptions on calls to remotable services within the same JVM if
the service method implementation is
236 not marked “allows pass by reference” or the service proxy used
by the client is not marked “allows pass
237 by reference”. [JCA20010]
IIUC, now we need to mark both the reference AND service method
implementation to "AllowsPassByReference" so that the runtime can
optimize the in-vm calls over remotable interfaces using PBR. This
seems to be too restrictive for the following use cases:
1. If the client component implementation knows that for a given
reference, the operations are safe to PBR because the client side
neither modifies the input parameters/return value/exceptions, nor
does it care if the these data are modified by the service side.
>
The "nor does it care" part of that is rather a bold assumption. If the
service retains a reference to a mutable return value after returning
from the method invocation, and modifies the contents of that value
before the client has had a chance to use it (for example, on a
different thread with higher priority), I very much doubt that using
PBR will produce correct results on the client side.
2. If the server component implementation knows that for a given
service method, the operation is safe to PBR because the server side
neither modifies the input parameters/return value/exceptions, nor
does it care if the these data are modified by the client side.
Similarly, if the client modifies the contents of a mutable input
parameter before the service has had a chance to use it (for example,
on a different thread with higher priority), I very much doubt that
using PBR will produce correct results on the service side.
Simon
For case 1 and 2, the PBR can be enabled independently without
knowing the counterpart. Does it make sense for SCA to allow PBR if
either reference OR service method implementation is marked
"AllowsPassByReference"?
Thanks,
Raymond
________________________________________________________________
Raymond Feng
rf...@apache.org <mailto:rf...@apache.org> <mailto:rf...@apache.org>
Apache Tuscany PMC member and committer: tuscany.apache.org
<http://tuscany.apache.org>
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
<http://www.tuscanyinaction.com>
Personal Web Site: www.enjoyjava.com <http://www.enjoyjava.com>
________________________________________________________________
