Hi!
I have a couple of issues with the FastKey tweak, which makes me think
that it's not very valuable.
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.
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.
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.
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
Comments?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
