>
> 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.
>
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
--
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".
