yeah, I also did the same thing. cheers Ana -----Original Message----- From: Gene Chuang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 1:05 PM To: 'Bhattacharyya, Ana'; '[EMAIL PROTECTED]' Subject: FatKey Pattern... was: Does it ever make sense to put amulti-be an-retur ningfindmethodin an entity bean? Hi Ana, Hey, glad to see that someone else has thought up of this pattern before, and that I wasn't the only crazy one! My FatKey class is my PrimaryKey class (my CustomPrimaryKey extends BeanDataContainer, hence making it a FatKey). This is also what I register in my DD; hence there's no need for 2 sets of PK classes. Besides, like you suspected, I don't think a bean can have 2 PK classes... you'll get CCExceptions along with other weird things! Actually, there is one other caveat with my FatKey pattern, and that is if a client (whether it be an entity bean, stateful session bean, servlet or app) decides to hold to a reference to an entity bean via it's pk (FatKey). If this key is then used in findByPrimaryKey, and it goes through my customized ejbLoad, dirty data will be loaded. Hence the obvious solution to this is the BeanData contained in the FatKey can only be used ONCE per ejbLoad; after ejbLoad is done with transferring the data over to the Bean, it needs to clear the FatKey data. Gene Chuang Teach the world... Join Kiko! <http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang> -----Original Message----- From: Bhattacharyya, Ana [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 7:44 AM To: Gene Chuang Subject: RE: Does it ever make sense to put amulti-bean-retur ningfindmethodin an entity bean? Hi Gene, I had implemented the same pattern some time back and got almost 7-8 times performance boost in Weblogic -- it works but the thing is that I was forced to use this fatkey as the PK - what my inital plan was to keep the normal 1 field key and extend the fatkey from that one -- but I started gettign ClassCastExceptions -- so I was forced to change to the fatkey in the DD level. Can I use 2 PK class one inheriting from the other for the same entity bean?? TIA Anamitra -----Original Message----- From: Gene Chuang [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 06, 2000 12:17 AM To: [EMAIL PROTECTED] Subject: Re: Does it ever make sense to put amulti-bean-retur ningfindmethodin an entity bean? 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". STATEMENT OF CONFIDENTIALITY. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify USPowerSolutions Corporation immediately at (617) 547-3800, or at [EMAIL PROTECTED], and destroy all copies of this message and any attachments. STATEMENT OF CONFIDENTIALITY. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify USPowerSolutions Corporation immediately at (617) 547-3800, or at [EMAIL PROTECTED], and destroy all copies of this message and any attachments. =========================================================================== 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".
