<vendor>
I hate questions like this, because I never know if readers follow the
Napoleonic Code when judging AppServer vendors, or use Common Law instead.
That is, I don't know if we are considered guilty until proven innocent,
or innocent until proven guilty. I guess I have to err on the conservative
side.
Both IAS and VisiBroker support optimized local calls, which avoid marshaling
in the case of caller and callee being in the same VM, and we have done so
for the last six years.
The twist that we apply in our EJB Container is to be very selective about
which parameters need to be copied. The vast majority of parameters passed
in a typical application are immutable. Parameter types such as "int",
"float", "java.lang.Integer", "java.lang.Float", "java.lang.String" etc.
are all immutable. Our EJB Container checks, on a method-by-method basis
which EJB method signatures contain mutable parameters. If a method contains
only immutable parameter types, we avoid the copying altogether. If a method
contains only one mutable parameter and any number of immutable parameters,
we only copy the one parameter. (Of course this type checking is done only
once, not every time a call is made, so it is very efficient.)
Furthermore, any copying is controllable. Currently it is controllable at
the VM (that is, EJB Container) level. We are looking to make the control
more fine-grained, so that individual methods can be marked as requiring
pass-by-value or not.
Since the vast majority of business logic written in Java does not rely on
pass-by-value semantics, we think this level of control is very useful in
optimizing your performance-critical EJB applications.
</vendor>
-jkw
Peter Delahunty wrote:
>
> Hi
>
> I realize this will be application server specific but does anyone know if
> local/remote method calls from EJB to EJB are optimized. For example if
> Entity Bean A calls Entity Bean B and they are both located in the same app
> server (e.g. now a local call) then does the app server optimize this call.
> What I mean is does the app server know that the call is local and so does
> not go through all the remote call overheads.
>
> To me the EJB spec seems to indicate that this sort of optimization should
> be done. For example if Entity Bean A calls Entity Bean B then I have to put
> an EJB reference in the deployment descriptor. Now to me this is telling the
> container which EJBs you are calling and so at deployment time the container
> works out if a call from Entity Bean A is a remote call to Entity Bean B by
> checking if the two beans will be on the same app server. if the situation
> changes eg Entity Bean B is put on a different app server then they will
> have to be re-deployed at which point the optomisation can be changed.
>
> Make perfect sense to me, or am i missing some thing....
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
