> -----Original Message-----
> From: Jonathan Weedon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 01, 2000 18:52
> To: [EMAIL PROTECTED]
> Subject: Re: Does it ever make sense to put a
> multi-bean-returning findmethodin an entity bean?
>
>
> 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
Mine, too. Passivation is not transparent perfomance-wise.
> 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
Ok. Using an application server of your choice, compose a list of 1,000,000
entities in a pool limited to 1,000 instances. Then do the equivalent using
JDBC. Assume that the table has 6 string columns, and that we want to list a
single column. Post the times.
The differences become even more pronounced when database capabilities
(aggregation, for example) are used. Then stateless session beans beat
entity beans by far.
> the case of composing a list without modifying the underlying
> entities, then
> the updates (which typically occur before the passivation)
> can be suppressed.
OK.
>
> 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.
You are incurring O(R) passivations. Since a passivated instance typically
goes to disk, this may be a heavy cost.
The only way I see to avoid the cost of passivation is to use EJB 2.0 and no
additional state beyond the CMP fields. This means that read-only instances
have zero size on disk.
>
> 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
- Avi
--
s/\be(\w+)/e-\1/g;
===========================================================================
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".
