Hi, > 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. Actually, I've designed a pseudo-pattern that does work within the EJB spec, is vendor-neutral, and allows BMP finder method to "load" all of the found beans in one SQL swoop, as long as findByXXX and subsequent ejbLoads are called within the SAME TRANSACTION. I've tested this pattern under Weblogic 5.1, and did get a nice performance boost; perhaps someone can implement and test this under a different server and tell us what the results are! I call my Pattern "Smart BMP Find using FatKeys". Here's how it goes: 1) All of my entity beans implement BeanDataContainer, a class that contains all the bean data (essentially a HashMap). This is a typical EJB pattern found in theserverside.com and is useful for bulk-retrival/updates; but as you will see, it's useful for my Fat Key implementation as well. 2) My custom primary key classes ALSO extend BeanDataContainer; hence my PK's have the capability of storing all of the data of the Bean it represents. 3) My findByXXX method starts with a typical single SQL call that returns me rows of matching bean data. In a "regular" implementation, I would just create a PK instance for each row's pk and return the collection. However, in my implementation I would fill each of my FatKey instance with data from the row, and return a collection of FatKeys. 4) The container does its magic by creating an EJBObject for each PK found in the returned collection; in my case, each EJBObject will be associated with a FatKey instead of a normal key! 5) In my ejbLoad implementation, I would first call getEJBObject().getPrimaryKey() and check if the returned instance is a FatKey. If so, just copy the data over from the FatKey's HashMap to the Bean's HashMap (remember, my beans extends BeanDataContainer as well!). Result? I call SQL select only ONCE in my entire transaction, instead of (1 + # found rows)! This saves many roundtrips to the database. However, this is definitely not as perfect as CMP's vendor-implemented "smart finds"; my pattern does contains 2 caveats: 1) Like I said before, your findByXXX call followed by subsequent business methods calls to the collection of return EJBObjects must all occur in the same transaction; otherwise you will risk getting dirty data! 2) When the container gets the Collection of FatKeys from ejbFindByXXX and associate it with EJBObjects, I'm not sure how close the association this is (by direct referencing, or RMI referencing, or JNDI lookup, etc..) Hence depending on the vendor implementation, when the client receives the serialized EJBObject from the Home interface, these EJBObjects may also drag along its associated FatKeys! HOWEVER, this is not as bad as it sounds! If, like me, you use the "Session Bean Accessing Entity Bean Facade Pattern", then your entity beans' clients are only session beans, which also reside on the same VM. This is prevent the the aweful FatKey serializations. What do you guys think of this pattern? Boon or bust? It works for me quite well in my architecture; lets see if it gives some else the same performance boost! Gene Chuang Teach the world... Join Kiko! <http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang> -----Original Message----- From: A mailing list for Enterprise JavaBeans development To: [EMAIL PROTECTED] Sent: 9/1/00 10:15 AM Subject: Re: Does it ever make sense to put amulti-bean-returningfindmethodin an entity bean? ***Please Note: This email was has been in a queue since Friday, September, 1. You may or may not have already received it. For more information, please contact [EMAIL PROTECTED] 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". ======================================================================== === 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".
