<vendor> stuff
On Sun, 5 Nov 2000 17:50:28 -0000, Peter Delahunty
<[EMAIL PROTECTED]> wrote:
>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.
<vendor name="jBoss">
jBoss automatically removes the RMI call overhead when doing intra-VM
calls. This is always "turned on".
jBoss optionally removes the copying of parameters for intra-VM calls,
as this can significantly improve performance. Especially in cases where
large XML-structures or similar are passed to servlets in the same JVM
this is beneficial. This allows us to get intra-VM calls between
servlets and EJB's that has been timed to as low as 0.4 ms per call. If
you really need that kind of perfomance, jBoss can do it for you :-)
</vendor>
>To me the EJB spec seems to indicate that this sort of optimization should
>be done.
This is partially incorrect. The pass by value semantics is specifically
enforced by the EJB specification. Optimization for local calls in terms
of removing network overhead is implementation dependent, but a very
common thing to do.
> 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.
<vendor name="jBoss">
In case of jBoss the above is (fortunately) incorrect. No matter where
your beans are located (same server, same cluster, or different
machine/cluster) you can *always* use the java:comp/env namespace to
reference it! We allow bean developers to put all their bean refrences
in ejb-jar.xml. For the case where the referenced bean is not on the
same server we add custom deployment information in our own jboss.xml
which points to the other server's JNDI binding of the bean. I.e. you
can let "java:comp/env/ejb/SomeBean" point to
"jnp://somehost/otherapp/SomeBean". Or you can even point to a bean
hosted by *another vendor's* server, i.e. let the JNDI name pointed to
be something like (in case of WebLogic hosted bean)
"t3://somehost/otherapp/SomeBean".
</vendor>
Also note that beans which are hosted on the same server, but in
different EJB JAR files, must also use the above linking facility. Are
you saying there are servers around that forces you to use
non-java:comp/env names in case the beans are not in the same JAR file
but on the same server?? To me that is very counter to the spirit of the
EJB specification.
regards,
Rickard, jBoss dev.
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
