Hi!
> I have a couple of issues with the FastKey tweak, which makes me think
> that it's not very valuable.
Please see my post to marc, "Re: [jBoss-Dev] Da solution".
> 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?
> 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.
Humm, I was just thinking at the design level. I guess this is an issue. A
biggy. One could argue "well, we could tweak the FastKey thing to make this
work", but I wouldn't go on "a tweak on a tweak" sort of thing.
> 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.
Must agree.
> 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? 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?
> 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
With the above issues (and the proposed enhancements) this would be
acceptable.
> 2. Make sure the tutorials point out this issue, and how to deal with it
This is one of the requirements for 1.
> 3. Use fairly large hashtables, which will have more effect on cache
> speed than the FastKey tweak
...raising jBoss' HW requisites :) - but acceptable.
> /Rickard
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
