db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tino Schöllhorn <t.schoellh...@plattform-gmbh.de>
Subject Re: Bug and proposed patch
Date Sun, 12 Dec 2004 18:45:07 GMT
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


Mime
View raw message