Yes, all/most vendors have this optimization ("me too").
But even with this and other optimizations I still don't advocate making
everything a bean. Beans still add overhead and baggage...
See the archives on bean granularity...
-Chris.
> -----Original Message-----
> From: Robert Castaneda [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 17, 2000 5:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Session EJBs vs. Java Objects
>
> <Vendor>
> >>Even if you do not perform the a remote method invocation, still EJB
> >>needs to deal with method parameters and return type through
> >>marshalling, which is dead slow on some JVMs. (On my machine everything
> >>slows down to 25%).
>
> Our Container and Visibroker have optimisations for this, where calls in
> the
> same vm can avoid marshalling. This is container dependant, not jvm
> dependant.
>
> </vendor>
>
> regards,
>
> -Rob
>
>
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Assaf Arkin
> Sent: Thursday, February 17, 2000 10:29 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Session EJBs vs. Java Objects
>
>
> EJB is pretty much your Java objects + RMI/IIOP + some EJB logic. That
> means you can expect it to be slower that plain Java objects.
>
> Even if you do not perform the a remote method invocation, still EJB
> needs to deal with method parameters and return type through
> marshalling, which is dead slow on some JVMs. (On my machine everything
> slows down to 25%).
>
>
> The Servlet 2.3 API supports the same transactions and JDBC connection
> pooling that is available for EJB, so if that's all you're looking for,
> consider running your database access from the Servlet itself.
>
> arkin
>
>
> Syed Fareed Ahmad wrote:
> >
> > Dear All,
> >
> > We are having severe performance problems. We have stateless EJBs
> (instantiated
> > from Servlets- WebSphere as the Application Server) to retrieve the Data
> from
> > Oracle DB. The performance is poor in the test environment. If I have
> the
> simple
> > Java Objects than the performance is much better. We need to install the
> system
> > into 1000+ concurrent user base. Will stateless Session EJB
> perform/scale
> better
> > than Java Objects in that environment as we have NO transactional
> requirements.
> > Of course I can make resource pools for the Simple Objects But does the
> Session
> > EJB benefit us in the Simple Inquiry Applications?
> > Should we go for Session EJBs or Simple Java Objects?. Can any body
> provide me
> > with some statistics for this question for my situation(1000+concurrent
> users)?
> >
> > Fareed Ahmad
> >
> >
> _________________________________________________________________________
> >
> > Disclaimer:
> >
> > "Any unauthorized form of reproduction of this message is strictly
> prohibited.
> > The bank does not guarantee the security of any information
> electronically
> > transmitted and is not liable for the proper and complete
> transmission
> of the
> > information contained in this communication, nor for any delay in its
> receipt.
> > THE USE OF EMAIL FOR ANY ILLEGAL PURPOSE OR FOR ANY PURPOSE OTHER
> THAN AS
> > PERMITTED BY THE BANK IS STRICTLY PROHIBITED AND SUCH USE MAY
> RESULT IN
> > DISCIPLINARY AND LEGAL ACTION."
> >
> >
> ==========================================================================
> =
> > 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".
>
> --
> ----------------------------------------------------------------------
> Assaf Arkin www.exoffice.com
> CTO, Exoffice Technologies, Inc. www.exolab.org
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
