> > 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.
Ok, I will repeat yet again, that this is not a tweak. The cache doesn't
work and won't in 90% cases (forget doco). We have a transparent way of
making it right and I will. You need to dive in the container invocation
layer to realize that only the cache needs to be aware of the key structure
hence the new concept of "cache key".
See my "da solution" post, where the cache introduces the "createCacheKey"
stuff, that is the only place we will have such a beast.
> > 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.
wrong, see my answer, orthogonal issues. We have EXACTLY the same situation
as current default PK.
> > 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
That is EXACTLY what is proposed in DaSolution, we pass Object and have it
orthogonal and the cache key provides implementation.
I would appreciate a little more faith and that you guys at least read my
mails :)
> 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.
Rickard, you need to think some more.
> > 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.
It is not an issue of speed (once again) it is an issue of "broken vs
works", in DaSolution I propose something that will make it transparent to
the Container architecture. I introduce what is imho a necessary concept,
the one of CacheKey, that is missing the previous design.
My first iteration of the solution (took me some time too) was not 100%
kosher since it exposed the FastKey at the JRMP layer and cache layer. I can
refactor these as proposed, think about it.
marc
>
> > /Rickard
> > --
> > Rickard �berg
> >
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >
>
>
>
