Dave,
<vendor>
Sorry to be yet another voice disagreeing with you, but I strongly
feel that what you are suggesting is wrong, and the more arguments
against what you say, the less likely that users will follow your
advise.
There are two flaws in your statement:
1) You make the claim that composing a list by accessing N entity
beans requires that N entity beans be in memory at any given time.
This is incorrect. The EJB 1.1 spec allows for entity beans to be
passivated during a transaction. A sophisticated container
implementation will take advantage of this by having a "working set"
of entity beans in memory at any given time. If you are working
through a large number of rows, the container can simply passivate
entity beans that were viewed previously in the transaction, and then
those same bean instances can be activated later to represent a
different row in the list. Thus, any size list can be view using a
finite number of beans (that is, where the total number of beans in
memory is smaller than the list size). In fact, one can view the
whole list using a single entity bean, if memory is that scarce.
Typically, it isn't.
2) You make the claim that supporting a large number of concurrent
users with entity beans will increase the demands on memory, verses
using stateless session beans. Again, this is incorrect. If you have
N users that each simultaneously want the same list, then you will
need N stateless session beans to access the information (and your
memory consumption is proportional to N). This is also the case with
entity beans. Thus, both cases are the same, in terms of memory
consumption.
If, on the other hand, your user access is scattered in time, as is
typically the case, then you probably are able to field the requests
with a single (or few) stateless session bean. (This was the point
you were making, I believe.) But if the requests are coming in
scattered in time, then you can likewise use use the same working set
of entity beans for the data access.
So on both counts, there is no memory advantage to using stateless
session beans over entity beans.
To follow up on that, the EJB 2.0 model then tips the scales in favor
of using entity beans. In EJB 1.1, data is accessed using public data
fields. Thus, if I have two concurrent transactions which need the
same set of rows at the same time, I need two copies of those rows,
regardless of whether I use stateless session beans or entity beans.
In EJB 2.0, entity data is accessed via getter methods. Thus, with
EJB 2.0, I can have one copy of the rows required by both
transactions, and only need two copies if either of the transactions
modifies the state (using standard "copy-on-write" techniques). Thus,
in EJB 2.0, I need half as much memory using entity beans as using
stateless session beans. With higher concurrency of read-mostly
beans, things get even better!
In summary, in EJB 1.1, the memory requirements are equivalent between
using stateless session beans and entity beans. In EJB 2.0, the
scales are tipped in favor of entity beans. Thus, IMO, it seems
ludicrous to suggest to users that they write all sorts of complicated
JDBC code (using stateless session beans) instead of having the
container do it for them (using container managed persistence), when
a good container can do it just as well, and in some cases better.
</vendor>
-jkw
Dave Wolf wrote:
>
> But there is one major difference. For the entity bean finder you will have
> N (n=rows) instances of an entity bean (and possible N*users) in memory for
> every row. Whereas one stateless session bean may be able to service
> multiple users and does not need one instance for every row. Each instance
> is a space in memory.
>
> IMHO I always use a session bean to find and an entity bean to change.
>
> Dave Wolf
> Internet Applications Division
> Sybase
===========================================================================
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".
