Hi Johnathan,
I see your concern; however I don't think my FatKey will break PrimaryKey
comparison... the reason why I say that is I believe it comes down to how I
implement the overloaded functions of PrimaryKey.hashCode() and
PrimaryKey.equals()... For my "regular" custom primary key classes, these
are overloaded to compare or hash the actual field value of the internal pk
(longs, in my case.) My FatKeys, which extend my CustomPrimaryKey, do NOT
overload these functions. Hence even if the "values" of my FatKeys change,
their comparison identity does not change.
Based on my logic above, I am assuming that server vendors implement
EJBObject.isIdentical the following way:
class EJBObject
{
boolean isIdentical(EJBObject aOtherObject)
{
return this.getPrimaryKey().equals(aOtherObject.getPrimaryKey());
}
}
I think its a pretty logical assumption that most if not all vendors
implement isIdentical this way... at least I believe Weblogic does because
I have implemented the FatKey pattern in my architecture and aside from the
significant performance boost, I have not witnessed any strange
side-effects.
Gene Chuang
Teach the world. Join Kiko!
http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang
----- Original Message -----
From: "Jonathan K. Weedon" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 06, 2000 1:23 PM
Subject: Re: FatKey Pattern... was: Does it ever make sense to put
amulti-bean-retur ningfindmethodin an entity bean?
> Gene,
>
> Actually, as far as I can see, there are a slew of problems with
> this FatKey pattern. The basic problem, that I can see, is that
> the EJB Container will use the primary key's value to create the
> EJBObject reference. If your primary key contains not only the
> primary key values, but also the other fields from the bean, then
> you can have different primary key values all corresponding to
> the same (logical) EJB.
>
> This will break things left, right and center for an EJB container.
>
> A short list of things that will be broken:
>
> 1) The EJBObject.isIdentical method will return false for two
> beans which are the same, but have different FatKeys.
>
> 2) The container's detection of local diamonds will be broken, as
> the contaienr will think that two (logically) identical beans are
> really different, because their primary keys differ.
>
> 3) The container's caches will be rendered useless because every
> time you modify an object, you are changing its FatKey, and the
> caches are keyed off the primary key's value.
>
> Let's look at a small example, and see how these things will be
> broken. Consider I have one transaction that uses a FatKey
> enabled finder method, and gets an instance of entity "Foo", and
> stores it into the local variable "foo1". Let's say that this
> same transaction modifies Foo (via foo1) and commits the
> transaction.
>
> Now, in a subsequent transaction I again use a FatKey enabled
> finder, and again get "Foo", and store it into the variable "foo2".
> How can I see the above failures:
>
> 1) If I call foo1.isIdentical(foo2) I will get false, where I
> should get true, because the primary key of foo1 is not the same
> as the primary key of foo2. (I assume that all EJB containers
> implement isIdentical by using the primary key, in some form. It's
> not clear that this method can be implemented correctly otherwise.)
>
> 2) If, in the second transaction, I use both foo1 and foo2, I will
> have two beans in memory, in the same transaction, each representing
> the same database row ("Foo"). If I modify the bean via foo1, I
> will not see those modifications if I use foo2, and vice versa.
>
> 3) When I go to commit this second transaction, which has modified
> the "Foo" record via both foo1 and foo2, there will be two calls
> to ejbStore (one for each of the instances) and probably only half
> the state will be updated (depending on how the updates are done).
> The containers are now both bloated and incorrect (with entries for
> both foo1 and foo2).
>
> Basically, the use of FatKeys, as you descibe, completely breaks
> the EJB Entity programming model. Primary keys should be immutable,
> in EJB.
>
> -jkw
>
> Gene Chuang wrote:
> >
> > 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>
>
>
===========================================================================
> 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".
