David, I'm not working this. Feel free to take a shot at it. I apologies in advance for the code not being documented well. The cmr code is not easy to understand because entities can not talk directly to each other, but must use the invoker chain.
One of the overall architectural problems of JBossCMP is database statements are tied directly to the ejb state (e.g., after ejbCreate and INSERT is always executed) and this needs to be removed before we can support more advanced db caching strategies. This requires a major rewrite and I don't expect to get to this until JBoss 3.1. When you come up with and idea on how to fix this send it to me, but make sure it does not violate the spec (read it carefully). -dain > -----Original Message----- > From: David Budworth [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 09, 2001 11:31 AM > To: JBoss-Dev > Subject: Re: [JBoss-dev] [ jboss-Bugs-478783 ] CMR records are deleted > out of order > > > Dain, > > Are you actively working on this? > I'd be happy to fix it (in the manner you suggest, not my > crack-induced > version of it) if you don't have the time. > > All I need is a pointer as to where the execution sequence > comes from. (I > suppose I could figure it out, but if you know where it is, > it'll save time) > > Not trying to push or anything, I just need to know if your > working on it so > I can get rid of my cascade-delete tags until the fix gets > comitted, or if I > should take a shot at fixing it since I have a re-producable > test case for it. > > Thanks, > -David > > > > > On Tuesday 06 November 2001 01:54pm, you wrote: > > Bugs item #478783, was opened at 2001-11-06 09:35 > > You can respond by visiting: > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=47 > 8783&group_id > >=22866 > > > > Category: JBossCMP > > Group: v2.5 Rabbit Hole (unstable) > > Status: Open > > Resolution: None > > Priority: 5 > > Submitted By: David Budworth (dbudworth) > > Assigned to: Dain Sundstrom (dsundstrom) > > Summary: CMR records are deleted out of order > > > > Initial Comment: > > In a 1:1 CMR, the master bean is deleted before the > > child bean. > > > > If you have: > > Order -> ShippingAddress > > With cascade delete turned on > > > > And you perform Order.remove() > > > > SQL Executed is: > > > > DELETE FROM order WHERE id = ? > > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > > > Which is really hard to do in a database > > > > I believe that it should be: > > DELETE FROM shippingaddress WHERE id = ? > > UPDATE order SET shippingaddress = ? WHERE id = ? > > DELETE FROM order WHERE id = ? > > > > (Yes, I know it doesn't make sense to update order > > right before you delete it, but it seems to be a > > byproduct of the interceptor stack system) > > > > Note: The above is a simplified version of my > > relations. My actual relation (in case it matters) > > is: > > Customer --1:n--> Order --1:1--> ShippingAddress > > And this happens when I call Customer.remove() > > > > > > > > > ---------------------------------------------------------------------- > > > > >Comment By: Dain Sundstrom (dsundstrom) > > > > Date: 2001-11-06 13:54 > > > > Message: > > Logged In: YES > > user_id=251431 > > > > You are on crack. :) > > > > The spec says "After the bean provider’s ejbRemove() > > method returns (and prior to returning to the client), the > > Container must remove the entity object from all > > relationships in which it participates, and then remove its > > persistent representation... After removing the entity > > object from all relationships and removing its persistent > > representation, the Container must then cascade the > > removal to all entity beans with which the entity had been > > previously been in container-managed relationships > > for which the cascade-delete option was specified." So this > > is what happens when you run order.remove(): > > > > 1. "the bean provider’s ejbRemove()method returns" > > > > 2. "remove the entity object from all relationships in > > which it participates" > > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > > > 3. "then remove its persistent representation" > > DELETE from order where id = ? > > > > 4. "cascade the removal to all entity beans with which the > > entity had been previously been in container-managed > > relationships for which the cascade-delete option was > > specified" > > DELETE FROM shippingaddress where ID = ? > > > > Follow? > > > > This means that not null foreign keys do not currently > > work. The spec did give us a way out of this in footnote > > 11 ("At this point it must appear to the application that > > the entity has been removed from the persistent store. If > > the container employs an optimistic caching strategy and > > defers the removal of the entity from the database (e.g., > > to the end of transaction), this must be invisible to the > > application."), but this feature has not been implemented > > yet. > > > > -dain > > > > > ---------------------------------------------------------------------- > > > > Comment By: David Budworth (dbudworth) > > Date: 2001-11-06 13:01 > > > > Message: > > Logged In: YES > > user_id=343354 > > > > Which spec version are you reading? > > ejb-2_0-fr-spec.pdf says: > > "As with the remove operation. the removal triggered by > > the cascade-delete option causes the container to invoke > > the ejbRemove() method on the entity bean instance that is > > to be removed before the persistent representation of that > > entity object is removed" > > > > That to me sounds like : > > shippingaddress.remove(){ > > DELETE FROM shippingaddress where ID = ? > > } > > order.store(){ > > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > } > > order.remove(){ > > DELETE from order where id = ? > > } > > > > Maybe I have the wrong spec? Or am I just on crack and > > not reading it correctly (entirely possible) > > > > > > > > > ---------------------------------------------------------------------- > > > > Comment By: Dain Sundstrom (dsundstrom) > > Date: 2001-11-06 10:12 > > > > Message: > > Logged In: YES > > user_id=251431 > > > > The ejb 2.0 final draft spec requires that the persistence > > representation is removed then the related entieites are > > cascad-deleted (section 10.3.4.2). This means that the > > following sql should be executed: > > > > UPDATE order SET shippingaddress_id = ? WHERE id = ? > > DELETE FROM order WHERE id = ? > > DELETE FROM shippingaddress WHERE id = ? > > > > The both of the sequences you present are wrong, so I'll > > check if the sequence I presented is occuring. Unless you > > can show me where in the spec your version is allowed, it > > won't be implemented. > > > > -dain > > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=47 8783&group_id >=22866 > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
