Charlie Alfred wrote:
> Richard Monson-Haefel wrote:
> > 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.
> >
>
> Would you also say that this analysis holds true if the EJB Server supports
> in-memory caching of read-mostly Entity Beans? Or, if it uses an EJB-side
> hot-cache with multi-version concurrency control, like eXcelon Corp's Javlin
> product?
Nice collection of buzz words, but most of them don't mean much in the context of
this discussion.
Relational databases also maintain a very fast and robust cache, which direct JDBC
access can leverage with each query. Front ending the database cache with an Object
Cache may have advantages when the database is only accessed by one EJB server, but
otherwise the performance gains are questionable. If your database is accessed by
several EJB servers or by a legacy systems and servers, then an object cache presents
a HUGE problem, cache coherence. How to do you make sure the object cache is in sync
with changes made to the database by other systems? You don't. You can't.
Lets face it, relational databases have been working on their cache technology for a
couple of decades (or more) while the EJB vendors have been developing it for a few
years (at best). When I need to share a database across several systems (legacy and
modern) I'll leverage a relational database cache so that all systems benefit from a
consistent view of the data. On the other hand, if I have a complex object model and
only access the database through one platform (like Gemstone/J) then an object cache
is great performance gain. Gemstone for example can maintain something like 6 Gig of
object cache in memory -- that's incredible and valuable under the right conditions.
>
>
> I can understand how the Servlet => JDBC path would be faster than the
> traditional Servlet => EntityBean => JDBC path, due to:
>
> * transaction overhead
> * bean passivation/activation if the EJB cache is full
> * additional client/server call, etc.
>
> However, unless I'm missing something, if the relevant info is cached then
> this overhead is significantly reduced on the EJB case. Its performance
> would be much closer to the straight JDBC case for the simple case (i.e.
> select of fields from few tables with simple joins). In the case where
> the read-mostly data takes on a more complex, object-oriented structure
> (such as a product catalog with lots of cross-references) the EJB cache
> might even have a much lower impedence mismatch for the Servlet.
>
There is no impedance mismatch issue with Servlets and JDBC. You access the data in
the same way its organized, relationally. There is, however, an impedance mismatch
anytime you model your business in objects and persist them to a relational database.
But this is besides the point. EJB is not objects in the purest sense of the
concept, they are components. You can't get the same flexibility from EJB that you
get from objects because beans must adhere to a component model which requires that
reference to other beans be remote. In a pure OO model, everything would be regular
references and you could do neat things like Fowler's architecture patterns. But
this is not the case in EJB and really has never been the case in distributed
objects. People who claim to have achieved all the benefits of OO business modeling
in distributed objects are fooling themselves, some others, but not experts in the
area. We do the best we can and model the business with components like EJB that
provide us with the closest thing to the OO nirvana while addressing more practical
issues of performance and scalablility.
It should be noted that I am a very big fan of EJB, perhaps one of the biggest.
Experience in actual large scale implementations have taught me the benefits that are
inherent in the EJB platform. At the same time I'm not blinded by loyalty to the
platform and believe that each technology has its place and that leveraging them
appropriately is more important then using them as a silver bullet.
Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
http://www.EjbNow.com
EJB FAQ
http://www.jguru.com/faq/EJB
===========================================================================
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".
