> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dan OConnor
> Sent: Monday, August 14, 2000 5:24 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] SPEEEEEEDDDD!!!! complex PK hashCode and equals
>
>
> On 14 Aug 00, at 17:14, marc fleury wrote:
>
> > In the case that the developer supplies a ComplexPK (aggregate
> of fields),
> > currently, we have no other choice but to rely on the hashCode
> and equals
> > that it supplies to do our internal EJB cuisine.
> >
> > does the spec say that you should overwrite hashCode and
> equals??? I don't
> > think so...
>
> Hi Marc,
>
> Yes it does, in 9.2.9. We should refuse to deploy an entity with a
> PK that does not override hashCode and equals.
OK that's good news....
1- It still remains that to ensure O(1) lookups, and hence a speedy
container *we* should provide that wrapper that returns an int on
hashCode... no need to go through heavy hash operations on EJB calls.
2- We should provide a second map for "findByPrimaryKey" that goes look on
the actual PK provided by the developer...
3- If a developer screws up his hashCode or equals (even I find it obscure
sometimes ;) we don't care and we ensure a fast operation
4- It is still *exactly* compatible... if I provide 2 i.e. a PK->wrapper map
Conclusion: it is fool-proof, fast, and transparent... what do you think...
regards
marc
>
> -Dan
>
> >
> > Here is my problem. I discussed it with Rickard back when he
> was designing
> > it and of course now it is broken :)))
> >
> > here is the deal
> > imagine
> > public Class MyPK {
> >
> > int id;
> > }
> >
> > in the entityPK tests in CVS this fails because we
> > 1- create with MyPK(10);
> > 2- the cache store a reference to the context under MyPK.hashCode (=
> > 00000001 for the sake of discussion)
> > 2- come back WITH THE SAME PK to ask for a method (set something)
> > 3- Of course since we serialize and deserialize the new MyPK
> (still holds 10
> > in this sense it is the same) has MyPK.hashCode = 00000000002 (it IS a
> > different object even though they are equal, get it).
> > 4- WE GET A CACHE MISS!!!!!!
> > 5- the cache says "no I don't have it" and goes on, as it
> should retrieving
> > an instance and initializing it to the values by DOING ejbActivate() AND
> > "ejbLoad()"
> > 6- Everytime we come back WE TALK TO A DIFFERENT INSTANCE :))))
> >
> > that's clearly f*cked up....
> >
> > all because the developer didn't specify an overriding hashCode
> and equals
> > in his PK.
> >
> > in jboss1.0 I had solved it in the following fashion:
> > every EJBObject (session or entity) had a unique identifier
> (creation time)
> > and that "EjbossPrimaryKey" was a wrapper for the "real" Object
> > dataBasePrimaryKey (could be a complex PK I didn't care )...
> > the end result is that we *never* miss a cache hit, even if the
> developer
> > did not supply hashCode and equals. Also we are *certain* that
> the stuff is
> > fast since we provide the hashCode for the wrapper...
> >
> > no offense, but clearly a superior design :))
> >
> > I wonder if some of the "speed" issues we have been seeing
> don't have to do
> > with the fact that an complex PK CMP (most CMPs) have an ejbActivate,
> > ejbLoad at *every* call, clearly a heavy operation.
> >
> > Listen Rickard, I will rewire this, but it might be deeper than
> we think (I
> > basically need to retool the way the lookups are done everywhere :((()
> >
> > I don't want to rely on the developer not forgetting to supply
> hashcode and
> > equals... it's obscure for most developers and will make the container
> > behave slowly..
> >
> > Unless of course it is specified in the spec....
> >
> > kind regards
> > (yet another night)
> >
> > marc
> >
> >
> > PS: I WILL SAY IT
> >
> > I AM SOOOOO FUCKING HAAAAAAAAPY!!!!!!!!!!!!!!!!!!!!!!!!
> > HEEE HEEE HEEE HEEEH EHEHEEHEHHEEEEEEEHEHEHEHEHEHEHEHEE
> > <KINGoTheWORLD/>
> >
> > Let's hope it significantly speeds things up... this could be the
> > "silliness" I was talking about with the discrepancy of speeds!!!!!!
> >
> > "I am papa large, big shout on the west coast"
> >
> > ________________________
> > Marc Fleury
> > Chief Technology Officer
> > Telkel, Inc.
> > ________________________
> >
> >
>
>
>
>
