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?
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.
Charlie Alfred
Foliage Software Systems
===========================================================================
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".
