The first rule in the pragmatic progammer book is get the damn thing
working as best as it can.
Reusing code is one way to do it, you get less bugs, easier
maintainability, etc.
But at the same time, code reuse tends to conflict with performance
issues.
The J2EE model is filled with such contradictions. Entity beans are
simply not optimized compared to what JDBC can offer in terms of
performance, especially when it comes down to the GUI side doning a lot
of queries, with only so much updates.
And no, the overhead is not 10%. 10% is the overhead of entity beans on
top of JDBC if you wrote the same code using JDBC. But you won't, with
JDBC you will write different code which is leaner and meaner, so the
overhead is substantially larger.
Also, if you cut the EJB server altogether and go directly to JDBC, the
difference is not 10%.
arkin
"Louth, William (Exchange)" wrote:
>
> So what your proposing is that we embed the database structure in 2 places.
> One in the servlet or servlet/session bean and the other in the entity bean
> persistence descriptor. Is there not some rule in the Pragmatic Programmer
> book about not duplicating such things. I have not got the book with me at
> the moment but I am sure its there anyway let common sense prevail for the
> time being.
>
> I have already posted a summary of a report which showed that using IAS 4.0
> that the overhead of using session bean talking to CMP entity beans (large
> collection) was small, less than 10%. I can trade that 10% against future
> maintenance and the all rest that comes with this approach. But I suspose If
> you are not using IAS 4.0 you better start writing SQL considering that
> using this method with other servers resulted in a 1800% overhead.
>
> William Louth
>
> > -----Original Message-----
> > From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> > Sent: Sunday, February 27, 2000 12:56 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: When to Use EJB? (was: Session EJBs vs. Java Objects)
> >
> > Doug has hit the nail on the head. EJB is appropriate for high volume
> > transactional sites like an electronic trading site, but for sites that
> > provide
> > read-only access to product catalogs or primarly textual material
> > (documents,
> > articles, etc..) with no transactional requirements, Servlets and JSP is a
> > better option. You should use EJB to handle purchases and transactions on
> > these
> > types of sites, but not for perusing the content.
> >
> > --
> > Author of Enterprise JavaBeans
> > Published by O'Reilly & Associates
> > http://www.EjbNow.com
> >
> > EJB FAQ
> > http://www.jguru.com/faq/EJB
> >
> >
> > "Bechtold, Douglas" wrote:
> >
> > > I hate to speak for Richard, but I think his point is that for read-only
> > > queries that are basically transaction-free that EJB is perhaps more
> > > overhead than is needed. I am working on exactly such a system where we
> > are
> > > considering using Servlets for queries that are for read-only purposes
> > and
> > > EJB for updates. If the query is for reading / writing, then the
> > "overhead"
> > > that EJB comes with is not an issue because of all of the other benefits
> > > that come with EJB.
> > >
> > > DB
> > >
> > > -----Original Message-----
> > > From: Frank D. Greco [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, February 24, 2000 9:26 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: When to Use EJB? (was: Session EJBs vs. Java Objects)
> > >
> > > >Ahi Satapathy wrote:
> > > >> So when EJB should be used ? what should be the factor one should
> > > consider
> > > >> before going to implement something with EJB ? If the site is not
> > > >> transactional, has no authorization security needs, and is read
> > only,
> > > should
> > > >> one go for simple Java Objects and use Servlets with direct JDBC
> > access
> > > ??
> > >
> > > At 05:13 PM 2/20/00 -0600, Richard Monson-Haefel wrote:
> > > >In a word, "maybe". You need an experienced architect (consult your
> > > >physician) to review your system and make a recommendation. Most
> > > >high volume sites (Amazon, eToys, et.) that have a lot of read only
> > >
> > > High volume as in number of concurrent visitors or number of
> > > transactions? Or high volume as in page throughput or http (or
> > > socket) throughput?
> > >
> > > >navigation and no transaction needs for the reads, should be
> > implemented
> > > >with something other then EJB - I like servlets. BUT, the purchasing
> > >
> > > Theoretically EJB can be used for high-volume sites like an
> > > electronic
> > > trading system. Architecturally, as part of an App Server
> > product,
> > > EJB
> > > should not be fundamentally slower than
> > Servlet/JDBC/JavaClasses.
> > > The
> > > vendor app server product should be able to scale much better
> > than a
> > > home-grown solution. If the home-grown solution is superior...
> > then
> > > I
> > > want to get in on the IPO... ;)
> > >
> > > >of goods and services on these sites should be implemented with EJB
> > via
> > > Servlets.
> > >
> > > Actually, are there 'rules of the road' for this stuff? What
> > are
> > > the
> > > heuristics for choosing a AppServer/EJB(et al) over a
> > > WebServer/Servlets?
> > >
> > > Frank G.
> > > +======================================================================+
> > > | Crossroads Technologies Inc, 55 Broad Street, 28th Fl, NYC, NY 10004 |
> > > | Dot-com Engineering |
> > > | Email: [EMAIL PROTECTED] Web: www.CrossroadsTech.com |
> > > | Voice: 212-482-5280 x229 Fax: 212-482-5281 |
> > > +======================================================================+
> > >
> > >
> > ==========================================================================
> > =
> > > 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".
>
> ***********************************************************************
> Bear Stearns is not responsible for any recommendation, solicitation,
> offer or agreement or any information about any transaction, customer
> account or account activity contained in this communication.
> ***********************************************************************
>
> ===========================================================================
> 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".
