I enjoyed reading through this thread. It had some very good technical
content. I was disturbed by the paragraph I clipped below:
Keep your personal opinions to yourself. Everyone has to learn and that
includes newbies...
>>I find it disturbing that a lot of people who BARELY understand Java try
to write
>> EJB's and use app servers; I find this notion ridiculous!
How do you propose we learn how to do this?
>>EJB and app
>>servers is NOT for beginning Java programmers. Sure a lot of vendors try
to
>>advertise otherwise (the bottom line is to sell as many units as possible,
>>right? :-)) by having snazzy GUI bean designers and deployers, but I
think
>>EJB is a technology that suited for intermediate to advanced developers...
>>hence that's why we're paid the big bucks, right? <<
I think the big bucks have gone to your head!
Regards,
Bryan Cooper
> ----------
> From: Gene Chuang[SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, September 07, 2000 12:45 AM
> Subject: Re: FatKey Pattern... was: Does it ever make sense to
> putamulti-bean-retur ningfindmethodin an entity bean?
>
> Hi Jonathan,
>
> You make many great points, and I really like the feedback; as I have
> previously said in another post, my FatKey pattern is up and running on
> our
> production site (kiko.com). SUPERFICIALLY, I see nothing happening out of
> the ordinary, but like you said, it's most likely because my pattern is
> almost tailored to Weblogic's app server (hence I guess my pattern isn't
> really vendor-neutral) AND my pattern is really tailored to my bean
> architecture (hence my pattern may not be even implementation-neutral!)
> But
> I do want comments like yours to try to poke holes in my little
> experiment... better to have us discover errors through discussion than
> through practice, right?
>
> I wholehearted agree with you that hashCode and equals functions are very
> difficult to implement, and that most java developers THINK they know how
> to
> implement these functions correctly or efficiently. In fact, if you hop
> over to newsgroups.bea.com (don't worry, I won't warn the BEA dudes that
> they've got an Inprise interloper!) you'll find that a large number of
> posts have to do with users not implementing these 2 functions correctly
> (or
> not implementing them at all!)
>
> However, I believe this is something that developers need to learn. If
> one
> has programmed Java, C or C++ long enough, one has come across situations
> where she MUST implement hashCode and equals: the most blatant example
> that
> comes to mind is using a custom key class for HashMap or HashSet. I find
> it
> disturbing that a lot of people who BARELY understand Java try to write
> EJB's and use app servers; I find this notion ridiculous! EJB and app
> servers is NOT for beginning Java programmers. Sure a lot of vendors try
> to
> advertise otherwise (the bottom line is to sell as many units as possible,
> right? :-)) by having snazzy GUI bean designers and deployers, but I
> think
> EJB is a technology that suited for intermediate to advanced developers...
> hence that's why we're paid the big bucks, right? :-)
>
> I can see the merits of Inprise alleviating the burden of Java developers
> having to implement these 2 functions by using the serialized bytes of a
> pk
> object to intrinsically implement hashCode and equals. However, one can
> also argue that you have stripped a power user the ability, even the
> option,
> to define how she wants to do equality and hash comparisons! And I think
> that's what the creators of Java intended: to allow users to implement
> these two functions so they can define the way they want objects to behave
> in a hash container such as HashMaps and HashSets, and in our case, EJB
> Key
> comparisons!
>
> Finally, you do drive a good point with your final observation: a FatKey
> can slip out of a transaction from which it was created without ejbLoad
> being called on it (client can call EJBObject.getPrimaryKey() and
> serialize
> it for later use, but NOT call any business methods that will result in a
> ejbLoad), and this "dirty" FatKey can slip into a subsequent transaction.
> But they way I see it, and correct me if I'm wrong, the only way a Primary
> key can be "reused" in a subsequent transaction is through
> findByPrimaryKey,
> right? So here's how I get around the stale key problem: In my
> findByPrimaryKey implementation (as opposed to my findByXXXX
> implementation), even though I get a FatKey passed in from the method
> argument, I recreate the FatKey again regardless of what's in the argument
> FatKey and return that to the container! Hence I guess the only really
> annoyance with a FatKey across transactions is that FatKey is, well, fat
> (and takes up memory)! But in my architecture I aways invoke business
> methods from the collection of EJBObjects I get from a findByXXX, AND I
> never really store a Primary Key for outside the transaction usage (I
> would
> store the Handle instead), so I managed to avoid this possible "loophole".
>
> Gene
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> To: [EMAIL PROTECTED]
> Sent: 9/6/00 5:19 PM
> 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".
