Hi!
marc fleury wrote:
> Rickard before we get too deep, fastKey is not an optimization. It makes
> the cache work on create and calls down the road on findbypk :).
Why doesn't it work on create and fBPK without fastKey?
> > 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.
>
> <g> long is what is used for stateful.
What do you mean?
> Again it is a problem of finding the stuff, like finding it! the fact that
> it is fast is a nice by product
For commit options B and C it will always be slower, for reasons
outlined. You want me to expand? Anything unclear?
> > 2 the whole tweak assumes that commit option A is used (i.e. keep state
> > as valid on commit). In general IMHO that will not be the case
> > (EJB-INTEREST discussions generally confirm this), because of other
> > systems accessing the database, and also for read/write entitybeans in a
> > clustered scenario option A will not work well (A will work well for
> > read-mostly though). So, if option B or C is used then the FastKey
> > lookup will almost always fail, and will be slower than if only regular
> > PK is used since almost all accesses will involve hashtable cache miss.
>
> .. as will the primary key operation ... what are you talking about....
I am talking about either 1 cache miss (regular PK only) or 2 cache
misses (fastKey). Guess which is slower.
> in this cache we pay a O(1) price instead of the potentially massive and
> unreliable PK price, think again.
No, you think again. You did not address point 4 at all. Since we cannot
make a faster cache without the developers help, fix 4 and that's it.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
