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.
flameRiskI 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
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. | |-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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
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 | | | | 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
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 [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
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 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
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 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
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?
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 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
