hummmmm
> I have a couple of issues with the FastKey tweak, which makes me think
> that it's not very valuable.
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 :).
> 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.
Again it is a problem of finding the stuff, like finding it! the fact that
it is fast is a nice by product
>
> 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....
in this cache we pay a O(1) price instead of the potentially massive and
unreliable PK price, think again.
> 3 I don't think FastKey can be used with RMI/IIOP. As you all know I
> don't like RMI/IIOP anyway, but IMHO we should still be able to support
> it decently if someone wants to have it.
wrong, If RMI/IIOP can pass a PrimaryKey Object then it can pass a Object as
cache key... orthogonal issues. In other words, either our proxies work or
they don't a key that has sense for the cache orthogonal. (we pass as
Object)
> 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.
>
> Those are the main issues, 2 and 4 being the biggest problems. So, IMHO,
> we should:
> 1. Go back to using just regular key for caching
> 2. Make sure the tutorials point out this issue, and how to deal with it
> 3. Use fairly large hashtables, which will have more effect on cache
> speed than the FastKey tweak
>
Rickard, let me deal with ease of use features will you, no offense meant :)
marc
> Comments?
>
relax, it only hurts in the beginning
> /Rickard
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
