<rant>
So you don't trust the developers. This has been a sore point with me over
the many years I have been a developer. The creators of the tool I need to
use often assume they are smarter than I am and therefore restrict my
ability to get real work done. I end up spending time trying to work around
the vendor's *features* when I should be solving business problems.
</rant>
-----Original Message-----
From: Jonathan K. Weedon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 06, 2000 7:20 PM
To: [EMAIL PROTECTED]
Subject: Re: FatKey Pattern... was: Does it ever make sense to
putamulti-bean-retur ningfindmethodin an entity bean?
Gene,
This is very interesting. I had forgotten that many EJB containers use
the equals() and hashCode() methods for primary key comparison. We do
not do this, and thus the difference. So, you may ask, why don't we
use these methods, and what do we do differently?
We don't use the user's implementation of equals() and hashCode() because
I don't trust developers to write these methods correctly. As is evidenced
by a number of threads on this topic, writing these methods correctly is
quite hard. In particular, the result of calling hashCode needs to be
uniformly
distributed for optimal dictionary lookup. Particularly when dealing with
numbers, it is easy to write a hashCode method which is very much non-
uniform. For example, simply OR'ing together your numeric fields makes for
a terrible hash, typically.
(Also, as I have pointed out in a previous thread, it is legal in EJB to
have
a Entity object reference as a CMP field, and thus it is legal to have such
a reference in a primary key field, and yet it is not possible to write the
hashCode/equals method on a class containing such a field.)
What do we do instead? We serialize the primary key to a chunk of bytes,
and then use internal hashCode/equals functions which runs against that
chunk of bytes. This is much faster than calling the equals/hashCode
methods, and results in a truly uniform distribution, resulting in fast
dictionary lookups, etc.
So, a question arises: which of us is breaking the rules?
I would say that you have broken a rule by writing a primary key class
which has hashCode/equals methods which are not written according to the
Java language specification. That is the equals method you have
implemented does not actually test the equality of the objects, but
only the equality of a subset of the fields. (And I admit that this
is a thin argument.)
On the other hand, you might argue that we are not compliant with the EJB
specification, in that we do not use on the user's implementation of
hashCode
and equals (bugs and all), but instead use serialization for comparison
purposes. (I don't see anything in the spec to preclude what we do, of
course.)
One last point, on the use of FatKeys. What would happen if you called the
multi-object finder in one transaction, and then used the object references
in another transaction. Previously, you said that you need to clear out
the data fields in your ejbLoad method, so that ejbLoad is only called
once. This is good. But what about if ejbLoad is never called in the
finder's transaction, but only in a subsequent transaction. Here, you would
still be loading the (potentially obsolete) state. Sound like the design
pattern is still broken, but for different reasons.
-jkw
Gene Chuang wrote:
>
> Hi Jonathan,
>
> 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
===========================================================================
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".
