Danny,
The answer (again) depends on your vendor's EJB Container
implementation.
Most EJB vendors usually have a pool (the size of which is
configurable) of entity beans. These are instances that
are not associated with any primary key.
Some EJB vendors have a cache of entity beans as well.
This cache hold entity bean instances that are associated
with a primary key. So, the container has to only
call the ejbLoad() on these to move instances into a state
where they can participate in transactions.
So far, so good. But we go a step further.
<vendor>
In addition to above, the Borland Enterprise Server (4.5.x
and above) can also handle a large number of entity beans
in a single transaction. Usually the concern when working
with a large number of entity beans in a single transaction
(such as a batch) is that:
- the resource usage in terms of memory increases
substantially
- there is a lot of overhead involved in instantiating a
large number of entity beans.
We get around both. In effect, we have a property (set in
the deployment descriptor) that controls the number of beans
in a single transaction. When the number of active beans
hits this threshold, beans are pushed back into the cache
(or pool). In effect, we have two "windows" - a window of
beans participating in the transaction and a window of beans
in the cache. The window of beans participating in the
transaction is a subset of beans in the cache. And it is
possible to "slide" these two windows across the total
ResultSet dynamically. Thus we can avoid the memory usage
increasing and also avoid the overhead of instantiating
a large number of entity beans (which a lot of other vendors
do!) by reusing instances from the cache/pool. Large scale
performance tests have shown that this implementation
provides a good space/time tradeoff, and the strategy is
extremely effective at keeping batch style operations
running in a controlled amount of memory, without impacting
the performance of other types of transactions that do
not exceed their transactional limits.
<vendor>
So, yes - entity beans are scalable in my opinion.
-krish
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Danny
Sent: Thursday, December 20, 2001 3:02 AM
To: [EMAIL PROTECTED]
Subject: Are CMP Entity Beans Scalable?
Has anyone used CMP entity beans in a large scale web application with success? If so
can you briefly describe how the CMP entity
beans were used in relation to the rest of the web app. I've developed a prototype
web app using session facades (for business
logic) which access CMP entity beans that use value objects for getting and updating
entity bean data. The book "Core J2EE Patterns
Best Practices and Design Strategies" recommends this approach for CMP entity beans.
It's easy enough to convert the CMP entity
beans to DAOs if needed, but if possible I would like to get the CMP entity beans to
work in a scalable manner.
Danny
===========================================================================
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".
