db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jakob Braeuchi" <jbraeu...@gmx.ch>
Subject Re: Bug and proposed patch
Date Mon, 13 Dec 2004 06:57:44 GMT
hi tino,

first i'll run the CollectionTests with ojb 1.0.x. then i'd like to
reproduce the behaviour you reported.

jakob

> Hi Jakob,
> 
> aehm. I think I missed a point. Will you add my patch to the source tree 
> of ojb?
> 
> Tino
> 
> Jakob Braeuchi wrote:
> > hi tino,
> > 
> > yes, i'll change the CollectionTest for ojb 1.1 and i'll also run these 
> > tests for ojb 1.0.x.
> > 
> > jakob
> > 
> > Tino Schöllhorn schrieb:
> > 
> >> Hi,
> >>
> >> so - if the tests are running fine (I suppose you changed the test) 
> >> then I wonder why I do have these problems when deleting a main 
> >> object. Do you have any ideas? With my proposed patch it runs fine - 
> >> if I not I either get ConcurrentModificationExceptions or one of those 
> >> references objects survives. Any ideas?
> >>
> >> Tino
> >>
> >> Jakob Braeuchi wrote:
> >>
> >>> hi tino,
> >>>
> >>> the manual deletion is done for relationships having auto-delete = 
> >>> false in testDeleteCollection() . 
> >>> testDeleteMainObjectWithOneToNRelation() also works without deleting 
> >>> CollectiblesC2 manually.
> >>>
> >>> jakob
> >>>
> >>> Tino Schöllhorn schrieb:
> >>>
> >>>> Hi Jakab,
> >>>>
> >>>> yes, you are right. The Collection is actually a 1:N-Collection. I 
> >>>> just looked at the source-code of 
> >>>> CollectionTest#testDeleteMainObjectWithOneToNRelation and in this 
> >>>> test the references are deleted manually. This is the main 
> >>>> difference in my point of view. The same with 
> >>>> CollectionTest#testDeleteCollection. So I think my described 
> >>>> use-case is not testd with those tests.
> >>>>
> >>>> Tino
> >>>>
> >>>> Jakob Braeuchi wrote:
> >>>>
> >>>>> hi tino,
> >>>>>
> >>>>> just to make sure: your test-case is actually a 1:n collection.
> >>>>>
> >>>>> how does your test differ from CollectionTest#testDeleteCollection

> >>>>> or CollectionTest#testDeleteMainObjectWithOneToNRelation ?
> >>>>>
> >>>>> in these testcases a main-object is deleted with it's associated

> >>>>> 1:n children (when auto-delete = object).
> >>>>>
> >>>>> jakob
> >>>>>
> >>>>> Tino Schöllhorn schrieb:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> yesterday I posted a problem in the user-list (Deleting 
> >>>>>> Main-Object and its association-objects). Currently there are
no 
> >>>>>> answers for this message. I looked further at the code of OJB.
The 
> >>>>>> method which is interesting at this point is 
> >>>>>> PersistenceBrokerImpl.deleteCollections(Object, List).
> >>>>>>
> >>>>>> Suppose you have the following case: Persons work at Projects
with 
> >>>>>> an associated Role. Now if you are deleting a Person-Object
or a 
> >>>>>> Project-Object you want to delete the corresponding Role-objects

> >>>>>> as well.
> >>>>>>
> >>>>>> Normally one can achieve that with *auto-delete=object* at the

> >>>>>> collections for the role-objects. But the current implementation

> >>>>>> does not work here correctly. If one has 3 or more role objects
to 
> >>>>>> be handled one gets a ConcurrentModificationException, like
this 
> >>>>>> one (line numbers have changed because of some change from me):
> >>>>>>
> >>>>>> java.util.ConcurrentModificationException
> >>>>>>     at 
> >>>>>>
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:448) 
> >>>>>>
> >>>>>>     at java.util.AbstractList$Itr.next(AbstractList.java:419)
> >>>>>>     at 
> >>>>>>
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.deleteCollections(PersistenceBrokerImpl.java:701)

> >>>>>>
> >>>>>>     at 
> >>>>>>
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.doDelete(PersistenceBrokerImpl.java:514)

> >>>>>>
> >>>>>>     at 
> >>>>>>
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.delete(PersistenceBrokerImpl.java:466)

> >>>>>>
> >>>>>>     at 
> >>>>>>
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.delete(DelegatingPersistenceBroker.java:170)

> >>>>>>
> >>>>>>     at 
> >>>>>>
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.delete(DelegatingPersistenceBroker.java:170)

> >>>>>>
> >>>>>>     at kos.generator.DataObject.delete(DataObject.java:106)
> >>>>>>     at 
> >>>>>>
> kos.intranet2.sandbox.DeletePersonTest.runTest(DeletePersonTest.java:64) 
> >>>>>>
> >>>>>>     at 
> >>>>>>
> kos.intranet2.sandbox.DeletePersonTest.main(DeletePersonTest.java:98)
> >>>>>>
> >>>>>>
> >>>>>> The current implementation looks like:
> >>>>>>
> >>>>>> if (cds.getCascadingDelete() == 
> >>>>>> bjectReferenceDescriptor.CASCADE_OBJECT) {
> >>>>>>     Object col = cds.getPersistentField().get(obj);
> >>>>>>         if (col != null)
> >>>>>>         {
> >>>>>>             while (colIterator.hasNext())
> >>>>>>                 {
> >>>>>>                     doDelete(colIterator.next());
> >>>>>>                 }
> >>>>>>         }
> >>>>>> }
> >>>>>>
> >>>>>> And the ConcurrentModificationException is thrown at the call
of 
> >>>>>> doDelete.
> >>>>>>
> >>>>>> If a am using OJB correctly this use-case should work. So I

> >>>>>> propose the following (but perhaps imperformant and inelegant)

> >>>>>> patch: The idea is simple. Instead of deleting the object 
> >>>>>> immediately from its origin-collection, copy the elements to

> >>>>>> another collection an use this for deleting.
> >>>>>>
> >>>>>> if (cds.getCascadingDelete() == 
> >>>>>> bjectReferenceDescriptor.CASCADE_OBJECT) {
> >>>>>>     Object col = cds.getPersistentField().get(obj);
> >>>>>>         if (col != null)
> >>>>>>         {
> >>>>>>         // Inelegant and brutal. but it works
> >>>>>>          Collection c = new java.util.ArrayList();
> >>>>>>                  while (colIterator.hasNext()) {
> >>>>>>                      c.add(colIterator.next());
> >>>>>>                  }
> >>>>>>                  Iterator j = c.iterator();
> >>>>>>                  while (j.hasNext())
> >>>>>>                  {
> >>>>>>                      doDelete(j.next());
> >>>>>>                  }
> >>>>>>         }
> >>>>>> }
> >>>>>>
> >>>>>> So do you think you could apply this patch - or am I mistaken
and 
> >>>>>> I am using OJB in a wrong way?
> >>>>>>
> >>>>>> With regards
> >>>>>> Tino
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >>>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> >> For additional commands, e-mail: ojb-dev-help@db.apache.org
> >>
> >>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message