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