Avi Kivity wrote:
> There is a slight difference: when using entity beans, the instance state
> must be kept for the duration of the transaction (i.e., the instance is
> associated with a transaction for the duration of the entire transaction,
> unless it is passivated). With stateless session beans, the instance is
> associated with the transaction only during the method call itself. This
> gives SLSBs reduced memory footprint over entity beans.
>
> Having said that, I agree that entity beans are the way to go in most cases.
Avi,
<vendor>
As you point out "when using entity beans, the instance state must be kept for
the duration of the transaction ... unless it is passivated". This was my
point: a container can (in EJB 1.1 or 2.0) passivate an entity bean within
the scope of a transaction. If I am composing a list of 1,000,000 rows, I can
implement this using a working set of 1,000 entity beans, or 1. The trick is
simply to passivate the beans after some period, within the transaction. In
the case of composing a list without modifying the underlying entities, then
the updates (which typically occur before the passivation) can be suppressed.
In summary, it is possible to compose a list consisting of an arbitrary number
of rows, using an entity bean finder method, and this can result in a single
SQL call going to the database. Furthermore, the list can be composed using
a finite (and potentially quite small) amount of memory.
In "big O" notation, if people are familiar with it, I am stating the
following:
With 1 concurrent user, using a stateless session bean to compose a list
consisting of R rows each with C columns takes O(C) memory.
Likewise, with 1 concurrent user, using an entity bean to compose a list
consisting of R rows each with C columns takes O(C) memory. (That is,
memory use is NOT proportional to the number of rows.)
With U concurrent users, using a stateless session bean to compose a list
consisting of R rows each with C columns takes O(U*C) memory.
Likewise, with U concurrent users, using an entity bean to compose a list
consisting of R rows each with C columns takes O(U*C) memory, in EJB 1.1.
However, with U concurrent users, using an entity bean to compose a list
consisting of R rows each with C columns takes O(C) memory, in EJB 2.0,
if the container implements copy-on-write. (That is, memory use is NOT
proportional to the number of concurrent users, as it is with stateless
session beans.)
So, from a theoretical standpoint, with EJB 1.1, stateless session beans
are equivalent to entity beans. In EJB 2.0, entity beans have a decided
advantage.
</vendor>
-jkw
===========================================================================
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".
