On Tue, Feb 8, 2011 at 11:17 AM, Simon Nash <n...@apache.org> wrote: > Mike Edwards wrote: >> >> On 08/02/2011 10:08, ant elder wrote: >>> >>> On Tue, Feb 8, 2011 at 9:56 AM, Simon Laws<simonsl...@googlemail.com> >>> wrote: >>>>> >>>>> 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 >>>>> >>>> >>>> Hi Ant. >>>> >>>> Can you say a bit more about the "situations when the assembler really >>>> knows it would be fine"? Reading previous posts to this thread doesn't >>>> convince me that that is the case. >>>> >>>> Simon >>>> >>> >>> We'll have to wait for Raymond to see if thats anything like his >>> situation, but there are lots of ways the assembler could know, he may >>> well have full access to the source but still be limited in making any >>> updates due to production lifecycle or control issues. This seems like >>> a similar situation as Java EE appservers have and I believe many >>> appservers have mechanisims for overriding and enabling PBR support in >>> their ORB or EJB modules to gain performance benefits. >>> >>> ...ant >>> >> Folks, >> >> One possibility to start with would be to add a Tuscany extension >> attribute which could be used by an Assembler to mark a particular service >> and/or reference as "AllowsPassByReference". >> >> This would cope with the situation where the Java components are not >> marked, but the assembler knows enough about them to know that the marking >> is correct. >> >> >> Yours, Mike. >> >> > I'm very dubious about the wisdom of this. I bear the scars from a > previous life of a situation where a flag was added to an enterprise > application server (which shall remain nameless) to override the PBV > semantics required by the architecture in the interests of performance > optimization when the user of the product "knew" that using PBR would > be safe. Needless to say, on a number of occasions this flag was set > incorrectly and this resulted in accusations of runtime bugs that were > eventually shown after laborious debugging to have been caused by the > PBR "optimization" being enabled incorrectly. > > IMO it's the implementation's responsibility to make the correct > assertions about whether it's PBR-safe. Implementations that don't > assert @AllowsPassByReference will have worse performance than those > that do support it. If a component developer cares about performance, > they need to code their implementation to play by the APBR rules and > turn on the flag to say they have done that. If the flag isn't turned > on by the implementer, I can't imagine that an assembler will have a > detailed enough knowledge of the implementation to be able to safely > provide the APBR assertion that the component developer couldn't/ > wouldn't/didn't provide. > > (Deep breath) Now I feel better after getting that off my chest :-) > > Simon > >
As an attempt to justify this: we don't have any samples that use @AllowsPassByReference, and I don't recall ever seeing many in Tuscany or elsewhere that do, but i think all those samples i've seen probably would have worked fine with it as they don't modify anything afterwards. I think it would be relatively uncommon to code something that would be unsuitable for using @AllowsPassByReference. So Joe developer writing his code probably wont use @AllowsPassByReference either, may not even know it exists, and any performance issues likely wont get found until much later when running in a production system by which time it can be very hard and time consuming to get the code modified, re-test, QA'd and redeploying into the live system. I don't know the circumstances around your example of it being hard to track down but i'll hazard a guess that that was at least partially due to firstly that the PBR override feature was poorly document and almost a "secret" option so developers/debuggers didn't know of its existence and secondly that the activation and logging of the feature was done out side of the application making it hard to see it was being used. The Tuscany extension approach would mitigate those by having the feature activated right in the application composite so its hard to miss and having clear logging messages when a composite is started where the feature is used. That said i've no time now so wont be implementing this but if someone else wanted to that would be ok to me. ...ant
