Thanks for the responses.  Your responses bring up another question though
(sorry!).

So, what you are saying is that if the classes for the Web application and
the EJBs are packaged in the same ear file, all calls between the Web
application and the EJBs will be optimized, as well as EJB-to-EJB calls. 
Otherwise, they are loaded with different class loaders and the calls must
be remote.  Starting to make sense.

My new improved question is:  If I deploy two EJBs in two different jar
files, are calls between them optimized?  Or, do they each get they're own
ClassLoader instance causing them to have to communicate via remote calls?

Thanks
Chris Murphy


On 2001.07.10 15:11 Scott M Stark wrote:
> Actually this is more correct than what I said. The strong type checking
> of
> Java won't allow a method invocation from a class loaded by one class
> loader on the same class loaded by another class loader, even if they
> have exactly the same bytecode. So only intra-ear calls are optimized.
> I'll double check this with a test case but this is how the code reads.
> 
> ----- Original Message -----
> From: "Julian Gosnell" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, July 10, 2001 12:27 PM
> Subject: Re: [JBoss-user] In VM optimization between JBoss and Servlet
> Container
> 
> 
> > This is my understanding of the situation.
> >
> > Provided that EJBs and Servlets/JSP are packaged within the same EAR
> file,
> the
> > J2EEDeployer will coordinate their deployment to the EJB and Web
> Containers.
> >
> > This coordination involves passing the same ClassLoader to both
> Containers.
> >
> > Any components deployed with the same ClassLoader SHOULD be able to
> talk
> to
> > each other directly (without serialisation of the call).
> >
> > i.e. If you have two components with high-bandwidth needs between them,
> deploy
> > them within the same EAR.
> >
> > If you deploy them separately you are not giving the J2EEDeployer any
> > information about which other components you would like to share a
> ClassLoader
> > with - so it has no way to perform this optimisation for you.
> >
> > I'm speaking with experience on the WebContainer side and extrapolating
> that
> > to the EJB side - so I am open to correction on this.
> >
> >
> > Jules
> >
> >
> >
> > "C Murphy @ Intechtual" wrote:
> >
> > > Hello,
> > >
> > > I'm working on a presentation for a client and I have a quick
> question
> > > about the optimization of in VM EJB calls in JBoss.  I read in the
> > > documentation about how EJB-to-EJB calls are automatically optimized
> by
> > > bypassing the network layer.  I didn't find any specific
> documentation,
> but
> > > it makes sense that calls from the Web/Servlet container to EJBs
> would
> also
> > > be optimized when they are running in the same VM.
> > >
> > > My question is: Is this true for the in VM Servlet container in all
> cases?
> > >
> > > The documentation talks about the differnce between internal
> references
> > > (Web App and EJBs deployed in an ear) and external references
> (deployed
> > > serperately).  Are the calls always optimized because they're in the
> same
> > > VM or does deploying them in seperate jar files  negate the
> optimization?
> > >
> > > I appreciate the help
> > >
> > > Chris Murphy
> > >
> > > _______________________________________________
> > > JBoss-user mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
> 
> 
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
> 

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to