Ok, Im gonna avoid the <vendor type=disagreement> tag :)
Here is my issue. I agree with much of what you have said until we get into
passivation. Are you saying that you would find the tradeoff of
serialization overhead to outweigh the memory overhead of the increased
number of entity beans? Serialization is a very intensive operation.
Im only speaking from my experiences where we found my proposed solution to
perform better. I do know that EJB 2 and some container enhancements will
address these issues but for today they exist. Im much more pragmatic then
many on this forum. You may disgree and thats fine, but its an important
consideration to take into account in your application when performance is
the need. When you need your app up and performing, Im willing to throw
academic theory to the wind.
Again, I accept our disagreement. If Im wrong so be it :)
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Weedon
> Sent: Friday, September 01, 2000 12:52 PM
> 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
> 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".
>
>
===========================================================================
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".
