Hi!
marc fleury wrote:
> 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).
Can you please explain what in the cache doesn't work without FastKey?
> 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".
Alright, fair enough. Diving.
> That is EXACTLY what is proposed in DaSolution, we pass Object and have it
> orthogonal and the cache key provides implementation.
Just because you can do it transparently doesn't mean it's a good thing.
> Rickard, you need to think some more.
Please rebut each point before saying that. Saying "You're wrong"
doesn't cut it.
> > > 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.
Explain what is broken. AFAIK you haven't.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
