Hi!
Hugo Jos� Pinto wrote:
> > The issues are:
> > 1 the use of "long" can only be temporary, since a java.rmi.server.ObjId
> > will have to be used in a clustered environment. And if ObjId's are used
> > the difference in computational speed of hashcode and equals compared
> > with a custommade key is much smaller.
>
> Simple is good. However, simple in long-term issues is better. :) One
> thought: couldn't we use a spatio-temporal GUID instead? Would it be easier
> on the CPU?
Please define "spatio-temporal GUID".
> > 4 The whole idea is based on the assumption that the developer is
> > incapable of properly creating primary key classes, i.e. ignorance. IMHO
> > that can be fixed with proper tutorials; it is not *that* difficult. I
> > think we will also see that the primary keys that people use will more
> > than often be enumerated keys, i.e. provide a good hash distribution,
> > again lessening the effect aginst FastKey.
>
> Couldn't we provide a default hashCode algorithm for them to use?
Some template or recommended code, yes.
> Or,
> someway (without killing nor the architecure nor the spec), generating an
> hash ourselves throught reflection (dream on, right)? Or, when the EJB
> verifier finds the absence of hasCode() in the PK, to point out some chapter
> of the doco where a sample implemntation lies?
The verifier should choke on missing hashCode and equals anyway. The
whole FastKey thing is more based on in-properly coded hashCode rather
than missing hashCode implementation.
> > 3. Use fairly large hashtables, which will have more effect on cache
> > speed than the FastKey tweak
>
> ...raising jBoss' HW requisites :) - but acceptable.
Make it customizable with decent defaults.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
