RE: [JBoss-dev] Where is everyone today?
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. 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. > > > 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 underlyi
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.
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.
> > > 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
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
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.
> > 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.
> > 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
interface, and are only valid for the term of the transaction (both of these
would have been a pain). I have most of the design on my white boards, note
pads and my head. I just need some solid time to finish the implementation.
> > Again, I don't know if I'm doing something wrong. I could post
> > the section
> > of code that does this, if it will help.
> >
>
> Why don't you check-in the code to your CMP directory structure? Then
> everybody can see it. This stuff is a "work in progress" anyways, isn't
it?
>
> Also, I'm interested in helping out with this relationship stuff. Danch
> probably is even more interested, but I can't speak for him.
>
> Regards,
> Bill
I'm not at a good breaking point right now, but I'll commit what I have
early next week.
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
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.
> 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 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!
...
}
> Again, I don't know if I'm doing something wrong. I could post
> the section
> of code that does this, if it will help.
>
Why don't you check-in the code to your CMP directory structure? Then
everybody can see it. This stuff is a "work in progress" anyways, isn't it?
Also, I'm interested in helping out with this relationship stuff. Danch
probably is even more interested, but I can't speak for him.
Regards,
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Where is everyone today?
Seems like it's always an interesting tradeoff of whether the code belongs in some runtime code (persistence manager) or in the generated code (CMP bean implementation)... I'm glad you're working on CMP 2.0, it will be good to have that implemented or JBoss. Cheers -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 3:22 PM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] Where is everyone today? Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:01 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Where is everyone today? > > > I would think you'd want to be out of the guts too, that just > seems a bit > too closely coupled with JBoss for the persistence manager. > Shouldn't the > CMP persistence manager be some type of layer on top (well > almost on top) > with a well defined interface? This should clearly tie in to > take advantage > of what the container can provide. > > I am definitely on the outside of JBoss though, so marc et al > are the people > to listen to. > > Cheers > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -----Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the trans
Re: [JBoss-dev] Where is everyone today?
Dain Sundstrom wrote: > Bill, > > Thanks for the reply. I really need other people thinking about this, > because I don't understand the rest of the container. > > 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. Errr. I was nervous enough about the persistence manager messing with its own bean's cache, let along messing with other bean's caches. > > 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. Ya, this makes me nervous too - there's too much that can go wrong. Really to get the store going you should be hooking into the transaction (which is the job of the EntitySynchronizationInterceptor) What about Bill's suggestion to go through the homes? That may not be the best performance, but then you know that all the Right Things are happening, even if (when) the definition of Right Thing changes. Short circuiting the interceptor chain is bad, IMHO. -danch ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Where is everyone today?
And if anyone bothers to check it, can someone please go thru the multiple datasources code I'd sent? It only makes sense to have it at a bean level - cannot think of an enterprise app connecting to single database! - Original Message - From: "Dain Sundstrom" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 29, 2001 8:22 PM Subject: RE: [JBoss-dev] Where is everyone today? > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > > -Original Message- > > From: Jay Walters [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:01 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > I would think you'd want to be out of the guts too, that just > > seems a bit > > too closely coupled with JBoss for the persistence manager. > > Shouldn't the > > CMP persistence manager be some type of layer on top (well > > almost on top) > > with a well defined interface? This should clearly tie in to > > take advantage > > of what the container can provide. > > > > I am definitely on the outside of JBoss though, so marc et al > > are the people > > to listen to. > > > > Cheers > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Friday, June 29, 2001 2:53 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Where is everyone today? > > > > > > Yo Dain, > > > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > > really worried that you are working directly with > > EntityEnterpriseContexts > > from the container.cache. Why aren't you going through the > > HOME interfaces > > to access related beans? Remember, each entity type can have entirely > > different datastores, caching mechanisms, locking mechanisms, > > synchronization mechanisms, and pooling mechanisms. You > > shouldn't really be > > circumventing how to access a bean. If I'm totally out of my > > league here, > > I'll just apologize and shut up. Let me know, but in the > > meantime, I'll try > > to review the CMP 2.x Relationships. > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Dain > > > Sundstrom > > > Sent: Friday, June 29, 2001 2:22 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: [JBoss-dev] Where is everyone today? > > > > > > > > > Is everyone on vacation? Is the list working? What-ever, > > doesn't really > > > matter. > > > > > > If any one is around today, and can reply to my message, I > > would greatly > > > appreciate it. I kind of need some guidance on the decision > > to create an > > > interceptor or not. I'm going to continue along the line that I > > > don't need > > > an interceptor (I can always add it later). > > > > > > If you all are on vacation, have a great time. > > > > > > -dain > > > > > > > -Original Message- > > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, June 28, 2001 11:48 PM > > > > To: '[EMAIL PROTECTED]' > > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > > > > marc, > > > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > > working using the > > > > entity cache, but it gives me a bad feeling. In the this > > > > case, there may be > > > > up to 4 beans that need to be stored: > > > > > > > > before: > > > > a1--b1 > > > > a2--b2 > > > > > > > > a1.setB(b2) > > > > > > > > after: > > > > a1\ b1 > > > > a2 \b2 > > > > > > > > So, I hold onto up to three other contexts. When my store is > > > > called, I write > > > > my state and then store
Re: [JBoss-dev] Where is everyone today?
The first implementation of the read-ahead messed around with the caches before I decided that I didn't like it and took that out. -danch Dain Sundstrom wrote: > Jay, > > Great point. Up until I started on this code, no part of JBossCMP worked > with the other container objects (cache, invoker etc); JBossCMP was executed > by the container via the persistence store interface. I'm going to have to > think about this. > > Thanks for helping to clarify my bad feeling, > > -dain > > >>-Original Message- >>From: Jay Walters [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:01 PM >>To: '[EMAIL PROTECTED]' >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>I would think you'd want to be out of the guts too, that just >>seems a bit >>too closely coupled with JBoss for the persistence manager. >>Shouldn't the >>CMP persistence manager be some type of layer on top (well >>almost on top) >>with a well defined interface? This should clearly tie in to >>take advantage >>of what the container can provide. >> >>I am definitely on the outside of JBoss though, so marc et al >>are the people >>to listen to. >> >>Cheers >> >>-Original Message- >>From: Bill Burke [mailto:[EMAIL PROTECTED]] >>Sent: Friday, June 29, 2001 2:53 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [JBoss-dev] Where is everyone today? >> >> >>Yo Dain, >> >>I know absolutely nothing about CMP 2.x Relationships, but it makes me >>really worried that you are working directly with >>EntityEnterpriseContexts >>from the container.cache. Why aren't you going through the >>HOME interfaces >>to access related beans? Remember, each entity type can have entirely >>different datastores, caching mechanisms, locking mechanisms, >>synchronization mechanisms, and pooling mechanisms. You >>shouldn't really be >>circumventing how to access a bean. If I'm totally out of my >>league here, >>I'll just apologize and shut up. Let me know, but in the >>meantime, I'll try >>to review the CMP 2.x Relationships. >> >>Bill >> >> >>>-Original Message- >>>From: [EMAIL PROTECTED] >>>[mailto:[EMAIL PROTECTED]]On >>> >>Behalf Of Dain >> >>>Sundstrom >>>Sent: Friday, June 29, 2001 2:22 PM >>>To: '[EMAIL PROTECTED]' >>>Subject: [JBoss-dev] Where is everyone today? >>> >>> >>>Is everyone on vacation? Is the list working? What-ever, >>> >>doesn't really >> >>>matter. >>> >>>If any one is around today, and can reply to my message, I >>> >>would greatly >> >>>appreciate it. I kind of need some guidance on the decision >>> >>to create an >> >>>interceptor or not. I'm going to continue along the line that I >>>don't need >>>an interceptor (I can always add it later). >>> >>>If you all are on vacation, have a great time. >>> >>>-dain >>> >>> >>>>-Original Message- >>>>From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] >>>>Sent: Thursday, June 28, 2001 11:48 PM >>>>To: '[EMAIL PROTECTED]' >>>>Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation >>>> >>>> >>>>marc, >>>> >>>>Do you mean that I should be setting invoked, or something else? >>>> >>>>I got the bi-directional one-to-one (enforced integrity) >>>>working using the >>>>entity cache, but it gives me a bad feeling. In the this >>>>case, there may be >>>>up to 4 beans that need to be stored: >>>> >>>>before: >>>>a1--b1 >>>>a2--b2 >>>> >>>>a1.setB(b2) >>>> >>>>after: >>>>a1\ b1 >>>>a2 \b2 >>>> >>>>So, I hold onto up to three other contexts. When my store is >>>>called, I write >>>>my state and then store the other contexts (with their >>>>respective mangers). >>>>This won't cause extraneous writes as 'tuned updates' is >>>> >>always on. >> >>>>What is giving me the bad feeling is I have just cut out all >>>>of the work >>>>that is being done in the interceptors, specifically >>>>Enti
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. 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. 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. Again, I don't know if I'm doing something wrong. I could post the section of code that does this, if it will help. -dain > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 1:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the transaction? Do I > > > need to lock the > > > context? What if one of the beans is removed? (the new remove > > > procedure for > > > relationships may handle this, but haven't implemented it yet) > > > > > > As you can tell this has given me a lot of concern. If > this is stuff I > > > shouldn't worry about, good. If I should worry, will it be > > > better to create > > > the new interceptor, thus reusing the code in the other > > > interceptors, or > > > will it be easier to handle the few special cases in the > > > persistence store? > > > > > > -dain > > > > > > > -Original Message- > > > > From: marc fleury [
RE: [JBoss-dev] Where is everyone today?
Jay, Great point. Up until I started on this code, no part of JBossCMP worked with the other container objects (cache, invoker etc); JBossCMP was executed by the container via the persistence store interface. I'm going to have to think about this. Thanks for helping to clarify my bad feeling, -dain > -Original Message- > From: Jay Walters [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:01 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] Where is everyone today? > > > I would think you'd want to be out of the guts too, that just > seems a bit > too closely coupled with JBoss for the persistence manager. > Shouldn't the > CMP persistence manager be some type of layer on top (well > almost on top) > with a well defined interface? This should clearly tie in to > take advantage > of what the container can provide. > > I am definitely on the outside of JBoss though, so marc et al > are the people > to listen to. > > Cheers > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 29, 2001 2:53 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Where is everyone today? > > > Yo Dain, > > I know absolutely nothing about CMP 2.x Relationships, but it makes me > really worried that you are working directly with > EntityEnterpriseContexts > from the container.cache. Why aren't you going through the > HOME interfaces > to access related beans? Remember, each entity type can have entirely > different datastores, caching mechanisms, locking mechanisms, > synchronization mechanisms, and pooling mechanisms. You > shouldn't really be > circumventing how to access a bean. If I'm totally out of my > league here, > I'll just apologize and shut up. Let me know, but in the > meantime, I'll try > to review the CMP 2.x Relationships. > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Dain > > Sundstrom > > Sent: Friday, June 29, 2001 2:22 PM > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-dev] Where is everyone today? > > > > > > Is everyone on vacation? Is the list working? What-ever, > doesn't really > > matter. > > > > If any one is around today, and can reply to my message, I > would greatly > > appreciate it. I kind of need some guidance on the decision > to create an > > interceptor or not. I'm going to continue along the line that I > > don't need > > an interceptor (I can always add it later). > > > > If you all are on vacation, have a great time. > > > > -dain > > > > > -Original Message- > > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 11:48 PM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > marc, > > > > > > Do you mean that I should be setting invoked, or something else? > > > > > > I got the bi-directional one-to-one (enforced integrity) > > > working using the > > > entity cache, but it gives me a bad feeling. In the this > > > case, there may be > > > up to 4 beans that need to be stored: > > > > > > before: > > > a1--b1 > > > a2--b2 > > > > > > a1.setB(b2) > > > > > > after: > > > a1\ b1 > > > a2 \b2 > > > > > > So, I hold onto up to three other contexts. When my store is > > > called, I write > > > my state and then store the other contexts (with their > > > respective mangers). > > > This won't cause extraneous writes as 'tuned updates' is > always on. > > > > > > What is giving me the bad feeling is I have just cut out all > > > of the work > > > that is being done in the interceptors, specifically > > > EntitySynchronizationInterceptor. For example, do I need > to remove the > > > context from the cache at the end of the transaction? Do I > > > need to lock the > > > context? What if one of the beans is removed? (the new remove > > > procedure for > > > relationships may handle this, but haven't implemented it yet) > > > > > > As you can tell this has given me a lot of concern. If > this is stuff I > > > shouldn't worry about, good. If I should worry, will it be > > > better to create > > > the new
RE: [JBoss-dev] Where is everyone today?
I would think you'd want to be out of the guts too, that just seems a bit too closely coupled with JBoss for the persistence manager. Shouldn't the CMP persistence manager be some type of layer on top (well almost on top) with a well defined interface? This should clearly tie in to take advantage of what the container can provide. I am definitely on the outside of JBoss though, so marc et al are the people to listen to. Cheers -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Friday, June 29, 2001 2:53 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Where is everyone today? Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, June 29, 2001 2:22 PM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-dev] Where is everyone today? > > > Is everyone on vacation? Is the list working? What-ever, doesn't really > matter. > > If any one is around today, and can reply to my message, I would greatly > appreciate it. I kind of need some guidance on the decision to create an > interceptor or not. I'm going to continue along the line that I > don't need > an interceptor (I can always add it later). > > If you all are on vacation, have a great time. > > -dain > > > -Original Message- > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 11:48 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > marc, > > > > Do you mean that I should be setting invoked, or something else? > > > > I got the bi-directional one-to-one (enforced integrity) > > working using the > > entity cache, but it gives me a bad feeling. In the this > > case, there may be > > up to 4 beans that need to be stored: > > > > before: > > a1--b1 > > a2--b2 > > > > a1.setB(b2) > > > > after: > > a1\ b1 > > a2 \b2 > > > > So, I hold onto up to three other contexts. When my store is > > called, I write > > my state and then store the other contexts (with their > > respective mangers). > > This won't cause extraneous writes as 'tuned updates' is always on. > > > > What is giving me the bad feeling is I have just cut out all > > of the work > > that is being done in the interceptors, specifically > > EntitySynchronizationInterceptor. For example, do I need to remove the > > context from the cache at the end of the transaction? Do I > > need to lock the > > context? What if one of the beans is removed? (the new remove > > procedure for > > relationships may handle this, but haven't implemented it yet) > > > > As you can tell this has given me a lot of concern. If this is stuff I > > shouldn't worry about, good. If I should worry, will it be > > better to create > > the new interceptor, thus reusing the code in the other > > interceptors, or > > will it be easier to handle the few special cases in the > > persistence store? > > > > -dain > > > > > -Original Message- > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 9:53 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > also be sure to report right here is you touch any of the > > > information in the > > > ctx (using setters) > > > > > > marcf > > > > > > |-Original Message- > > > |From: [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On > > > Behalf Of Dain > > > |Sundstrom > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > |To: '[EMAIL PROTECTED]' > > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > | > > > | > > &g
RE: [JBoss-dev] Where is everyone today?
Yo Dain, I know absolutely nothing about CMP 2.x Relationships, but it makes me really worried that you are working directly with EntityEnterpriseContexts from the container.cache. Why aren't you going through the HOME interfaces to access related beans? Remember, each entity type can have entirely different datastores, caching mechanisms, locking mechanisms, synchronization mechanisms, and pooling mechanisms. You shouldn't really be circumventing how to access a bean. If I'm totally out of my league here, I'll just apologize and shut up. Let me know, but in the meantime, I'll try to review the CMP 2.x Relationships. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Dain > Sundstrom > Sent: Friday, June 29, 2001 2:22 PM > To: '[EMAIL PROTECTED]' > Subject: [JBoss-dev] Where is everyone today? > > > Is everyone on vacation? Is the list working? What-ever, doesn't really > matter. > > If any one is around today, and can reply to my message, I would greatly > appreciate it. I kind of need some guidance on the decision to create an > interceptor or not. I'm going to continue along the line that I > don't need > an interceptor (I can always add it later). > > If you all are on vacation, have a great time. > > -dain > > > -Original Message- > > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 11:48 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > marc, > > > > Do you mean that I should be setting invoked, or something else? > > > > I got the bi-directional one-to-one (enforced integrity) > > working using the > > entity cache, but it gives me a bad feeling. In the this > > case, there may be > > up to 4 beans that need to be stored: > > > > before: > > a1--b1 > > a2--b2 > > > > a1.setB(b2) > > > > after: > > a1\ b1 > > a2 \b2 > > > > So, I hold onto up to three other contexts. When my store is > > called, I write > > my state and then store the other contexts (with their > > respective mangers). > > This won't cause extraneous writes as 'tuned updates' is always on. > > > > What is giving me the bad feeling is I have just cut out all > > of the work > > that is being done in the interceptors, specifically > > EntitySynchronizationInterceptor. For example, do I need to remove the > > context from the cache at the end of the transaction? Do I > > need to lock the > > context? What if one of the beans is removed? (the new remove > > procedure for > > relationships may handle this, but haven't implemented it yet) > > > > As you can tell this has given me a lot of concern. If this is stuff I > > shouldn't worry about, good. If I should worry, will it be > > better to create > > the new interceptor, thus reusing the code in the other > > interceptors, or > > will it be easier to handle the few special cases in the > > persistence store? > > > > -dain > > > > > -Original Message- > > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, June 28, 2001 9:53 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > > > > also be sure to report right here is you touch any of the > > > information in the > > > ctx (using setters) > > > > > > marcf > > > > > > |-Original Message- > > > |From: [EMAIL PROTECTED] > > > |[mailto:[EMAIL PROTECTED]]On > > > Behalf Of Dain > > > |Sundstrom > > > |Sent: Thursday, June 28, 2001 9:45 PM > > > |To: '[EMAIL PROTECTED]' > > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > | > > > | > > > |> | The only way I can find to get a ctx for a pk > > > |> |is from EntityInstanceInterceptor, and the only way to > > get to the > > > |> |EntityInstanceInterceptor is container.invoke(mi). > > > |> > > > |> no no no it's in the cache, > > > |> > > > |> container.cache.get(id) (or something like that) > > > |> > > > |> marcf > > > |> > > > | > > > |YES! Thanks so much. I didn't want to write the interceptor. > > > |This is going > > > |to be way easier. I'm going to go code now. &g
[JBoss-dev] Where is everyone today?
Is everyone on vacation? Is the list working? What-ever, doesn't really matter. If any one is around today, and can reply to my message, I would greatly appreciate it. I kind of need some guidance on the decision to create an interceptor or not. I'm going to continue along the line that I don't need an interceptor (I can always add it later). If you all are on vacation, have a great time. -dain > -Original Message- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 28, 2001 11:48 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > marc, > > Do you mean that I should be setting invoked, or something else? > > I got the bi-directional one-to-one (enforced integrity) > working using the > entity cache, but it gives me a bad feeling. In the this > case, there may be > up to 4 beans that need to be stored: > > before: > a1--b1 > a2--b2 > > a1.setB(b2) > > after: > a1\ b1 > a2 \b2 > > So, I hold onto up to three other contexts. When my store is > called, I write > my state and then store the other contexts (with their > respective mangers). > This won't cause extraneous writes as 'tuned updates' is always on. > > What is giving me the bad feeling is I have just cut out all > of the work > that is being done in the interceptors, specifically > EntitySynchronizationInterceptor. For example, do I need to remove the > context from the cache at the end of the transaction? Do I > need to lock the > context? What if one of the beans is removed? (the new remove > procedure for > relationships may handle this, but haven't implemented it yet) > > As you can tell this has given me a lot of concern. If this is stuff I > shouldn't worry about, good. If I should worry, will it be > better to create > the new interceptor, thus reusing the code in the other > interceptors, or > will it be easier to handle the few special cases in the > persistence store? > > -dain > > > -Original Message- > > From: marc fleury [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, June 28, 2001 9:53 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > > > > > also be sure to report right here is you touch any of the > > information in the > > ctx (using setters) > > > > marcf > > > > |-Original Message- > > |From: [EMAIL PROTECTED] > > |[mailto:[EMAIL PROTECTED]]On > > Behalf Of Dain > > |Sundstrom > > |Sent: Thursday, June 28, 2001 9:45 PM > > |To: '[EMAIL PROTECTED]' > > |Subject: RE: [JBoss-dev] CMP 2.x Relationships Implementation > > | > > | > > |> | The only way I can find to get a ctx for a pk > > |> |is from EntityInstanceInterceptor, and the only way to > get to the > > |> |EntityInstanceInterceptor is container.invoke(mi). > > |> > > |> no no no it's in the cache, > > |> > > |> container.cache.get(id) (or something like that) > > |> > > |> marcf > > |> > > | > > |YES! Thanks so much. I didn't want to write the interceptor. > > |This is going > > |to be way easier. I'm going to go code now. > > | > > |-dain > > | > > |___ > > |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 > > > > ___ > 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
