I will say it clearer:
developer are going to shoot themselves in the foot with equals and hashCode
(hey even I "a recognized authority and published author" in the EJB field
did not remember it :))) Also that will be hard to diagnose imho.... pain on
the list and "bwaaaa it's slow" messages in the pipe.
If they do, they are in deep doo-doo and we are in deep doo-doo because the
container is slow.
If they do and we tell them "not-good" they can't deploy their beans and
need to understand 9.2.9
Even if they do it right (override) we still depend on their hashing and
there are even more ways to shoot yourself in the foot there (e.g. the
recent discussion on array[], can be black-magic for most developers,
including me).
PLUS PLUS PLUS we have no way of controlling that speed, we depend on them
and their shot foots...
With the solution I propose
1- We get constant speed, in every case (several shots in the foot included)
2- Only the findByPrimaryKey is unsolvable (even if we don't do it, it is
the case today)
3- we always deploy -> percieved "ease of use" of jboss, a BIGGY in my book
as you know:)
4- I would agree that we should say "warning!, no hash and equals provided,
bad bad boy!"
You know what Dan?, this is a no-brainer, just work for me, but *only* gain
down the road
because even in the case of 4 only findByPrimaryKey speed is affected (will
have a cache miss) but at least the normal invocation is ALWAYS O(1) (never
cache missed!), can *you* beat that?
code,
I mean
love,
marc
> > -----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.
> > > ________________________
> > >
> > >
> >
> >
> >
> >
>
>
>
