On Tue, Feb 8, 2011 at 12:25 AM, Raymond Feng <enjoyj...@gmail.com> 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. > 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. > 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). > Thanks, > Raymond > ________________________________________________________________ > Raymond Feng > 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 >
I can see that relaxing the current spec restrictiveness would be difficult as things would break in some circumstances, but it does seem like there will be situations when the assembler really knows it would be fine but even so they can't get the PBR optimization because the impls aren't coded with the @AllowsPassByReference annotation. Isn't that a similar situation to where the remotable annotation was added to the interface SCDL element, and there could be a similar allowsPassByReference attribute added to the service and reference SCDL elements? ...ant
