Richard Monson-Haefel wrote:
> Do you use bean passivation during transactions for BMP entities or only CMP
> entities. Just curious. I'm assuming its just for CMP since you would need to
> manage the instance variable's state if you did it for BMP, which would probably
> cause a performance degradation over simply using more bean instances.
Richard,
<vendor>
Unfortunately, I don't see that this level of performance can be achieved within
the scope of the EJB spec for BMP beans. But the issue is not what you point out.
The use of a working set (which is smaller than the total number of entity beans
accessed in a single transaction) is valid either for BMP or for CMP beans. Of
course, with BMP beans, the container cannot detect that the beans were modified
or not (within the scope of the spec, at least) and thus ejbStore will be called
on each bean before it is passivated. A well-written BMP bean can have this store
be a noop if the bean's state was not modified. So I don't see any issues with
managing instance variable state.
However, there IS a performance issue with BMP, which has to do with their
finder methods. There is no way (within the EJB spec) to avoid loading in
each BMP bean one at a time. That is, I can't load the state of all the BMP
beans at the time that I issue the SELECT for the finder method. Instead, I have
to go back to the database to get the rows. (Of course, if I am using Option A,
I can get the entities from the cache, but the point here was that there are a
large number of rows, which cannot reasonably be kept in memory at any one time,
which obviates the caching.) With CMP, I can load the state of the beans using
a single SELECT.
That being said, I must admit that this working set capaibility is an often
requested feature which has not yet been implemented in IAS. I have a prototype
working, and I am optimistic that the feature will be available in our next
release. But, no, we don't actually do this correctly today.
Some readers may assume I suppressed this information in my original posting in
order to hide a limitation of IAS. This is not the case. In fact, I am very
happy to discuss the limitations of IAS, because the limitations of our product
stand up so nicely when compared with the limitations of competing products.
But rather, my reason for supressing this information was that:
1) There has been a strong desire to limit vendor-specific discussions. I very
much endorse this! And I might remind posters that this rule should apply both
for "proprietary" products, and "open" products. (Including Sun's J2EE RI.)
2) I did not want to give readers any excuse for using stateless session beans
instead of entity beans, simply due to a limitation in our product. The arguments
that I presented are valid, even if the feature discussed is not available in
the current release of our particular product.
</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".
