As soon as you go to an object caching solution, it is a whole new ball game
as you are relying on proprietary technology to get the performance that you
need. If this is acceptable, by all means utilize the available tools in
the marketplace. If you are relying upon a proprietary caching mechanism,
you could cache objects whether your strategy is to use JSP/Servlets to
fetch data or Entity Beans. Since the gain from not having to go to the DB
would then be the same either way, JSP/Servlets will still have less
overhead for read-only queries than an Entity bean solution due to the
transaction overhead, security checking, potentially remote invocations,
etc. Richard pointed out some of these issues, but it ended up on a
different thread I think.
DB
-----Original Message-----
From: Charlie Alfred [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 03, 2000 5:45 AM
To: [EMAIL PROTECTED]
Subject: Re: When to Use EJB? (was: Session EJBs vs. JavaObjects)
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".
===========================================================================
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".
