> I suggest that we deploy any entity whose primary key overrides
> both methods (assuming it passes all other tests), and refuse to
> deploy any entity whose primary key fails to override either.
>
> I believe that providing a more complete "suitability" test would be
> difficult beyond any value that it had.

I agree, also since most hashing algorythms are "application dependent" (for
example we hash the fastKey to the Long value at creation, which has NO
meaning whatsoever but to the developer) we can't really devise ANY strategy
that I can think of.

Also the scope of the problem is smaller with the introduction of the
fastKey concept. It will only remain on lookups in the cache by PrimaryKey
(they WILL happen but...).  In clear this problem *will*  exist in *every*
java EJB container, but the scope of it in jboss2.0 is drastically reduced.

marc

>
> -Dan
>
>
> >
> > -- Juha
> >
> >
> >
> >
>
>
>
>


Reply via email to