Hi marc!
> 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.
I initially agrred with this one. This weekend I've digged thru the jBoss
source (hoping I could, easily, do this and then - "tchadam!" - arrive
monday to the list with the miracle solution) but today I'm not so sure.
What could read out of it - but I can be wrong - is that jBoss' JRMP
implementation is tightly coupled with the idea of strict spec compliance -
using the bean's PK.
I found that I could easily modify
src/main/org/jboss/ejb/ContainerInvoker.java
src/main/org/jboss/ejb/plugins/jrmp/interfaces/EntityProxy.java
src/main/org/jboss/ejb/plugins/jrmp/interfaces/HomeProxy.java
src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java
src/main/org/jboss/ejb/plugins/jrmp12/interfaces/EntityProxy.java
src/main/org/jboss/ejb/plugins/jrmp12/server/JRMPContainerInvoker.java
src/main/org/jboss/ejb/plugins/jrmp13/interfaces/EntityProxy.java
src/main/org/jboss/ejb/plugins/jrmp13/server/JRMPContainerInvoker.java
but that when it came to these next ones,
src/main/org/jboss/ejb/plugins/BMPPersistenceManager.java
src/main/org/jboss/ejb/plugins/CMPPersistenceManager.java
src/main/org/jboss/ejb/plugins/EntityInstanceInterceptor.java
src/main/org/jboss/ejb/plugins/EntitySynchronizationInterceptor.java
src/main/org/jboss/ejb/plugins/NoPassivationEntityInstanceCache.java
src/main/org/jboss/ejb/plugins/RandomEntityInstanceCache.java
...I noticed that I was dealing with stuff that could not only be used by
JRMP but also by SOAP or IIOP. There could have been one other level of
indirection, or abstraction, in this code, so that we would be able to have
implementations of Persistence Managers without knowing about FastKeys at
all, and then possibly write specific code to handle this elsewhere
(subclasses?).
This gets me to the point: can it really be possible to modify jBoss'
implementation cleanly *WITHOUT* ruining its beautiful architecture?
I may be missing some stupid point anyway, and perhaps all this mumbo-jumbo
could easily be modified to work cleanly after all without this mess of
mine. Do you have any comments? Guys?
PS: I really didn't what a simple iterrogative post of mine to bruing up all
this mess, nor am I just tring to "show off" in the list. Nobody likes a
smart ass, and neither do I. I just felt that going specific "FastKey" on an
architcture-level issue "Object" could bring trouble in the future.
Hugo Jos� Pinto
> 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); file://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
> > >
> > >
> >
> >
> >
>
>
