Hi,
Optimization is one aspect - but keep in mind that your exposing
putting aside the concern about misuse of my component (internal apps
mainly)....
Is using a non-proxied component to make service method calls order of magnitude faster or slightly faster or is it pretty much given that if you want faster calls on your service methods, you should use non-proxied components as first choice?
I guess one way to ask this is: if you guys(avalon developers) out
there working for a client who has a requirement to have a "very fast
service" implementation, would make "non proxiing" your service
component as one of your first choices to optimize your service.
My first choice - go for classic proxied components or components designed and implemented with defensive mechanisms - but that more a case of elevated priorities that I have related to components I'm developing with a priority on broad reusable in any environment. The reuse aspect may not be a high priority in a closed component environment in which case I would suggest throwing together a test case to qualify the performance impact on method invocation and them make a judgment based on the results relative to you priorities.
Keep in mind that the method invocation cycle is just one aspect that your need to consider and its impact is relative to the overall service invocation overhead. In some scenarios the proxy overhead is insignificant relative to the service execution - in others its significant.
Generally speaking - given a choice between a well protected component and a few extra dollars on hardware - I'll go for the well protected component because priority on speed is (a) transient, (b) relatively inexpensive to resolve, and (c) potentially much more expensive in the long term if not dealt with during initial design/deployment phases.
Stephen.
regards Korosh.
lifecycle interfaces which means that consumers (which you have no control over) can potentially do things to your component. However - you can code against this but ensuring that your lifecycle operations are only invoked once and throwing an illegal state exception otherwise - etc. Other example of the need for non-proxied component exposure include things like org.omg.corba.ORB which is itself a class that is acting as a big proxy to an underlying implementation.
All you need to worry about is a little defensive programming on the lifecycle stage operations - but aside from that - no problem.
Stephen.
Korosh.
On Sat, 2004-01-31 at 01:12, Stephen McConnell wrote:
john lukar wrote:
I can be making 100's of such method calls on my service per second and speed is important.
What you can do is disable proxy generation for a particular component. This is needed sometimes for objects that are themselves acting as proxies. The solution is to include the attribute key "urn:activation:proxy" with a value of "false" in the xinfo <type> <info> <attributes> element.
For example:
<type> <info> <name>simple</name> <lifestyle>singleton</lifestyle> <attributes> <attribute key="urn:activation:proxy" value="false"/> </attributes> </info> : </type>
This is not tied into the meta-info generation at this time (we still need to add generic attribute handling) - so you going to have to maintain the xinfo file manually and make sure it is included into the target/classes directory after the avalon:meta and before the jar:jar goal. BTW - there is an example of this in one of the test cases in the activation impl package. Just search for "urn:activation:proxy".
Steve.
thanks for information on this.
John.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
