OK I am "refactoring" my own XP :)))
the right way to do it is that we DO propagate the "Object" throughout.
The way to introduce the FastKey is to have the cache itself say : "this is
how I want to see my Object key"...
in other words, ALL the ID creation done in the container should really say
Object cacheId = getCache.generateCacheKey(id);
containerInvoker.getEntityEJBObject(cacheId);
where id is the base Object id, i.e. the PrimaryKey supplied by the client.
This way we can plug in cache and their way of managing internal keys (maybe
direct DB keys or FastKeys) or just the current way of doing it, which in
the case of the (broken) base would be
NoPassivationInstanceCache {
public Object generateCacheKey(Object id) {
return id; // ;-)
}
In the case of FastKey would be
NoPassivationInstanceCache {
return new FastKey(id); //and basta
}
the old code comes back in the container, but works, and only the cache
needs to be aware of it, not even the JRMPcontainer invoker needs to know
about it. The local proxies still need to be able to interpret a fastKey
but that is about it.
One way to make the client transparent is to provide a Loose object that can
take native keys and or cache keys (like the FastKey today but without the
typing)... next XP excercise :)))
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> Sent: Friday, August 18, 2000 8:57 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] Marc (& Rickard): Architecture "tweak"?
>
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> > Sent: Friday, August 18, 2000 8:42 AM
> > To: jBoss Developer
> > Subject: Re: [jBoss-Dev] Marc (& Rickard): Architecture "tweak"?
> >
> >
> > Hi!
> >
> > marc fleury wrote:
> > > > This is what I pointed to in my post: "Re: [jBoss-Dev] what is
> > > > fastCache". I don't agree with this change too. Should be
> Object, and
> > > > then cast to FastKey for our impl.
> > >
> > > Not a problem, minor.
> >
> > Why do you want the architecture to be reliant on this tweak? It seems
> > like an implementation choice for the distribution plugin+cache.
>
> Rickard when I say "not a problem, minor" i mean, not a problem
> to change to
> Object (i have to rethink about it)...
>
> Also, let's stop the design bla bla for a second.
>
> It didn't work. It works now.
>
> I will try to code it Object. Like I said I started by doing
> that, cause I
> know you pus*ies don't like interface changes, I then decided to
> do FastKey
> to make it work and compile. To factor the implementation to
> Object is NOT
> A PROBLEM!
>
> marc
>
> PS: One thing I REALLY want to do is fix the cache lookup and locking
> mechanism... bad if you ask me <g>. Interfaces are cheap.
>
>
>
>
> >
> > /Rickard
> >
> > --
> > Rickard �berg
> >
> > Email: [EMAIL PROTECTED]
> > http://www.telkel.com
> > http://www.jboss.org
> > http://www.dreambean.com
> >
> >
>
>
>
