Hi Jonathan,
What I had done and I am pretty sure what Gene has done is the equals() and
hashcode() method calculate or compare only the unique pk fields -- its
only that along with the pk fields I have the other fields in the table
also.
So it will be unique as the equals and hashcode are implemented using only
the pk fields.
Correct me if I am wrong.
Ana
-----Original Message-----
From: Jonathan K. Weedon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 4:24 PM
To: [EMAIL PROTECTED]
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".
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".
