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.
-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.
> ________________________
>
>
