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