The bean developer uses the home/remote interfaces, Dain is building the
plumbing that makes it transparent to the bean developer. For example if
the bean developer adds an object to a 1:n CMR under the covers the
container/persistence manager/CMP beans need to get data into the bean and
the database about that relationship. The most efficient way to do all this
is probably not with client visible features, though it isn't clear to me
that they can't be in the CMP bean implementation class as opposed to being
in interceptors and what not.
How fat is your CMP bean implementation class right now Dain? You might
want to consider putting more of this stuff in there at the remote/home
interface level as a way to build it more quickly and easier to validate
correctness. They you could always push code further into the container
later to optimize portions which don't perform.
Cheers
-----Original Message-----
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 02, 2001 9:36 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Where is everyone today?
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dain
> Sundstrom
> Sent: Saturday, June 30, 2001 2:48 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Where is everyone today?
>
>
>
> ----- Original Message -----
> From: "Bill Burke" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, June 29, 2001 3:11 PM
> Subject: RE: [JBoss-dev] Where is everyone today?
>
>
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On
> Behalf Of Dain
> > > Sundstrom
> > > Sent: Friday, June 29, 2001 3:16 PM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [JBoss-dev] Where is everyone today?
> > >
> > >
> > > Bill,
> > >
> > > Thanks for the reply. I really need other people thinking about this,
> > > because I don't understand the rest of the container.
> > >
> >
> > IMHO, you shouldn't have to understand the rest of the
> container. If you
> > use the HOME interfaces, everything will be abstracted out and
> taken care
> of
> > for you.
>
> I agree. I can't exactly use the home interface. The home
> interface doesn't
> have commands such as 'set you foreign key for this relation ship
> to 42.' I
No, but setRelationshipA(BeanA) could call BeanA.getPrimaryKey().
> think I need to implement an interceptor to handle special messages. This
> would be simmilar to how entity synchronization works. I doesn't really
> matter at this point, because I have figgured out how to implement it in a
> way that adding the interceptor later will be simple.
>
If a method call on an entity is successful, an InstanceSynchronization is
registered with the transaction. At the end of the transaction, the TM
loops through all registered synchronizations, and storeEntity is called if
isModified is true or the bean is dirty. Now, if there is no transaction,
storeEntity will be called after every entity method invocation.
> > > Here's the deal. I delegate the actual storage of the other updated
> > > contexts to the their respective persistence storage managers, so they
> get
> > > stored by correct data source. I also get references to the
> other beans
> > > through their container's cache.
> > >
> >
> > Again, why do you talk directly with the Persistent managers? Entities
> > always know when they have to store themselves. You really
> don't have to
> > worry about it.
>
> I do, if I don't have an interceptor. Store is only called from
> the entity
> synchronization interceptor, and I'm currently not going through the
> interceptor chain. So, someone has to call store.
>
Again, IMHO, you really should be going through the interceptor chain.
<flameRisk>I really think you have a design flaw here, if you need to access
the EntityEnterpriseContexts directly, and really should revisit why you
need to do so.</flameRisk>
> > > I think the biggest problem with this implementation is that my
> > > persistence
> > > store is directly calling store on other persistence stores, thus
> > > by passing
> > > all of the code that is supposed know the right way to do this.
> > >
> >
> > I just read a little about the CMR stuff in the spec. Seems
> pretty nasty
> to
> > implement and probably effects more things than just the
> persistent store.
> > It seems that Relationships must be first class remote objects that wrap
> > access to their underlying entities. I'd be curious to know how you
> handle
> > one-to-many relationships i.e.
> >
> > from the spec:
> >
> > public void changeTelephoneNumbers()
> > {
> > Address a = getShippingAddress();
> > Address b = getBillingAddress();
> > Collection c = b.getTelephoneNumbers();
> > a.setTelephoneNumbers(b.getTelephoneNumbers());
> > if (c.isEmpty()) { // must be true!
> > ...
> > }
>
> Wel, I don't handle 1-n relationships yet, but it is not as hard as you
> think. Relationship collections are not allowed to be passed
> over a remote
Sounds fishy. I need to read the spec again, but wouldn't this make
Relationship collections totally useless? Who would ever use them if you
couldn't access them through their entity's remote interface? I should stop
commenting until I read more on the spec.
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
