You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Tino Schöllhorn <t....@plattform-gmbh.de> on 2004/12/12 12:13:48 UTC
Bug and proposed patch
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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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
Re: Bug and proposed patch
Posted by Oliver Zeigermann <ol...@gmail.com>.
Ah, thanks for explaining :)
I forgot about that one...
Oliver
On Sun, 12 Dec 2004 17:52:48 -0600, Chris Lamprecht
<cl...@gmail.com> wrote:
> It can happen with two threads, but it can also happen in this
> situation (which I've seen several times):
>
> Iterator iterator = myCollection.iterator();
> while (iterator.hasNext()) {
> Object foo = iterator.next();
> if (something is true about foo) {
> myCollection.remove(foo); // INCORRECT! Must call
> iterator.remove() instead
> }
> }
>
> So the mistake is, you can't call remove() on a collection while
> you're iterating through it -- instead you need to call
> iterator.remove(), which removes the last object you got from
> iterator.next(). It won't complain on the call to
> collection.remove(), but next time you call iterator.next(), it will
> throw a ConcurrentModificationException.
>
> -Chris
>
> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>
>
> <ol...@gmail.com> wrote:
> > Hi Tino,
> >
> > I am a newbie to OJB, but AFAIK a concurrent modification exception
> > will be thrown only when there are two concurrent changes to the same
> > list. This can only be the case when there are two threads working on
> > the same collection. How can this happen?
> >
> > Can you explain why you think your patch works?
> >
> > Oliver
> >
> > On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
> >
> >
> > <t....@plattform-gmbh.de> wrote:
> > > 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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi tino,
i'm glad the hear it's not an ojb-problem. i do not have a ready-to-use solution
for your referential integrity problem, but you could eventually defer ri
handling until the tx is committed by implementing the PBStateListener interface.
jakob
Tino Schöllhorn schrieb:
> Hi Armin, hi Jakob,
>
> well - after a long time I think I finally found the problem. Thanks for
> your support. The problem was create by me: we have a persistent base
> class which called method of PersistenceBrokerAware#afterDelete. This
> method disconnected the deleted object of other connected object. So far
> so good. But since we implemented referential integrity on the
> object-model the following remove-calls changed the currently iterated
> collection of PersistenceBrokerImpl#deleteCollections.
>
> So the described behaviour which I thought was an error of ojb is not
> really an error of OJB, but was introduced by me. But - if one wants to
> implement referential integrity it would be very useful if OJB used my
> patch ;-)
>
> Or do you have another idea how to implement referential integrity in a
> better safe way? Currently I am using this approach:
>
>
> class ProjectPerson {
> public void setProject(kos.intranet2.om.Project project) {
> kos.intranet2.om.Project oldValue = this.project;
> this.project = project;
> if (project != null &&
> !project.getProjectPersons().contains(this)) {
> project.addProjectPerson((kos.intranet2.om.ProjectPerson)this);
> }
> if (oldValue != null && !oldValue.equals(project)) {
>
> oldValue.removeProjectPerson((kos.intranet2.om.ProjectPerson)this);
> }
> }
>
> public kos.intranet2.om.Project getProject() {
> return project;
> }
>
> public void setPerson(kos.intranet2.om.Person person) {
> kos.intranet2.om.Person oldValue = this.person;
> this.person = person;
> if (person != null && !person.getProjectPersons().contains(this)) {
> person.addProjectPerson((kos.intranet2.om.ProjectPerson)this);
> }
> if (oldValue != null && !oldValue.equals(person)) {
>
> oldValue.removeProjectPerson((kos.intranet2.om.ProjectPerson)this);
> }
> }
> }
>
>
> Do you have any proposals/hints for this?
>
> Regards
> Tino
>
>
>
>
> Armin Waibel wrote:
>
>> sorry, missing part of a sentence.
>>
>>> Hi Tino,
>>>
>>> Tino Schöllhorn wrote:
>>>
>>>> Hi Jakob,
>>>>
>>>> it would be great if you could integrate it. Where exactly the
>>>> element is removed from the collection I do not know either. I'd
>>>> thought you could help here. But anyway: if the modified code is
>>>> checked in it works great and should'nt have any side effects.
>>>>
>>>
>>> Think we need an test case to reproduce your test. Could you modify
>>> an existing test (e.g. using CollectionTests) to reproduce your problem?
>>>
>>> As PB-api is not thread-safe (each thread have to use it's own PB
>>> instance)
>>
>>
>>
>> and your test is a single threaded one,
>>
>>> the error could only happen when OJB itself try to remove an object
>>> from the Iterator. If this is the case OJB has a bug in handling
>>> deleted objects and should be fixed IMO without copy the referenced
>>> objects (if this will not be possible, your patch should be applied).
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> With regards
>>>> Tino
>>>>
>>>>
>>>>
>>>> Jakob Braeuchi wrote:
>>>>
>>>>> hit tino, chris,
>>>>>
>>>>> i can integrate your patch into delteCollections(), but i still do
>>>>> not see
>>>>> where the element is removed from the collection. doDelete()
>>>>> deletes the
>>>>> item from the db.
>>>>>
>>>>> jakob
>>>>>
>>>>>
>>>>>> Hi Chris,
>>>>>>
>>>>>> you're absolutely right and exactly that happens in the
>>>>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>>>>> that not every Iterator-type supports the remove method. So I
>>>>>> proposed a patch that works even if the used Iterator doesn't support
>>>>>> Iterator#remove.
>>>>>>
>>>>>> With regards
>>>>>> Tino
>>>>>>
>>>>>> Chris Lamprecht wrote:
>>>>>>
>>>>>>> It can happen with two threads, but it can also happen in this
>>>>>>> situation (which I've seen several times):
>>>>>>>
>>>>>>> Iterator iterator = myCollection.iterator();
>>>>>>> while (iterator.hasNext()) {
>>>>>>> Object foo = iterator.next();
>>>>>>> if (something is true about foo) {
>>>>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>>>>> iterator.remove() instead
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> So the mistake is, you can't call remove() on a collection while
>>>>>>> you're iterating through it -- instead you need to call
>>>>>>> iterator.remove(), which removes the last object you got from
>>>>>>> iterator.next(). It won't complain on the call to
>>>>>>> collection.remove(), but next time you call iterator.next(), it will
>>>>>>> throw a ConcurrentModificationException.
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>>>>> <ol...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Hi Tino,
>>>>>>>>
>>>>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>>>>> will be thrown only when there are two concurrent changes to the
>>>>>>>> same
>>>>>>>> list. This can only be the case when there are two threads
>>>>>>>> working on
>>>>>>>> the same collection. How can this happen?
>>>>>>>>
>>>>>>>> Can you explain why you think your patch works?
>>>>>>>>
>>>>>>>> Oliver
>>>>>>>>
>>>>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>>>>
>>>>>>>>
>>>>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
Hi Armin, hi Jakob,
well - after a long time I think I finally found the problem. Thanks for
your support. The problem was create by me: we have a persistent base
class which called method of PersistenceBrokerAware#afterDelete. This
method disconnected the deleted object of other connected object. So far
so good. But since we implemented referential integrity on the
object-model the following remove-calls changed the currently iterated
collection of PersistenceBrokerImpl#deleteCollections.
So the described behaviour which I thought was an error of ojb is not
really an error of OJB, but was introduced by me. But - if one wants to
implement referential integrity it would be very useful if OJB used my
patch ;-)
Or do you have another idea how to implement referential integrity in a
better safe way? Currently I am using this approach:
class ProjectPerson {
public void setProject(kos.intranet2.om.Project project) {
kos.intranet2.om.Project oldValue = this.project;
this.project = project;
if (project != null && !project.getProjectPersons().contains(this)) {
project.addProjectPerson((kos.intranet2.om.ProjectPerson)this);
}
if (oldValue != null && !oldValue.equals(project)) {
oldValue.removeProjectPerson((kos.intranet2.om.ProjectPerson)this);
}
}
public kos.intranet2.om.Project getProject() {
return project;
}
public void setPerson(kos.intranet2.om.Person person) {
kos.intranet2.om.Person oldValue = this.person;
this.person = person;
if (person != null && !person.getProjectPersons().contains(this)) {
person.addProjectPerson((kos.intranet2.om.ProjectPerson)this);
}
if (oldValue != null && !oldValue.equals(person)) {
oldValue.removeProjectPerson((kos.intranet2.om.ProjectPerson)this);
}
}
}
Do you have any proposals/hints for this?
Regards
Tino
Armin Waibel wrote:
> sorry, missing part of a sentence.
>
>> Hi Tino,
>>
>> Tino Schöllhorn wrote:
>>
>>> Hi Jakob,
>>>
>>> it would be great if you could integrate it. Where exactly the
>>> element is removed from the collection I do not know either. I'd
>>> thought you could help here. But anyway: if the modified code is
>>> checked in it works great and should'nt have any side effects.
>>>
>>
>> Think we need an test case to reproduce your test. Could you modify an
>> existing test (e.g. using CollectionTests) to reproduce your problem?
>>
>> As PB-api is not thread-safe (each thread have to use it's own PB
>> instance)
>
>
> and your test is a single threaded one,
>
>> the error could only happen when OJB itself try to remove an object
>> from the Iterator. If this is the case OJB has a bug in handling
>> deleted objects and should be fixed IMO without copy the referenced
>> objects (if this will not be possible, your patch should be applied).
>>
>> regards,
>> Armin
>>
>>
>>> With regards
>>> Tino
>>>
>>>
>>>
>>> Jakob Braeuchi wrote:
>>>
>>>> hit tino, chris,
>>>>
>>>> i can integrate your patch into delteCollections(), but i still do
>>>> not see
>>>> where the element is removed from the collection. doDelete() deletes
>>>> the
>>>> item from the db.
>>>>
>>>> jakob
>>>>
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> you're absolutely right and exactly that happens in the
>>>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>>>> that not every Iterator-type supports the remove method. So I
>>>>> proposed a patch that works even if the used Iterator doesn't support
>>>>> Iterator#remove.
>>>>>
>>>>> With regards
>>>>> Tino
>>>>>
>>>>> Chris Lamprecht wrote:
>>>>>
>>>>>> It can happen with two threads, but it can also happen in this
>>>>>> situation (which I've seen several times):
>>>>>>
>>>>>> Iterator iterator = myCollection.iterator();
>>>>>> while (iterator.hasNext()) {
>>>>>> Object foo = iterator.next();
>>>>>> if (something is true about foo) {
>>>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>>>> iterator.remove() instead
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> So the mistake is, you can't call remove() on a collection while
>>>>>> you're iterating through it -- instead you need to call
>>>>>> iterator.remove(), which removes the last object you got from
>>>>>> iterator.next(). It won't complain on the call to
>>>>>> collection.remove(), but next time you call iterator.next(), it will
>>>>>> throw a ConcurrentModificationException.
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>>>> <ol...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Tino,
>>>>>>>
>>>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>>>> will be thrown only when there are two concurrent changes to the
>>>>>>> same
>>>>>>> list. This can only be the case when there are two threads
>>>>>>> working on
>>>>>>> the same collection. How can this happen?
>>>>>>>
>>>>>>> Can you explain why you think your patch works?
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>>>
>>>>>>>
>>>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: Bug and proposed patch
Posted by Armin Waibel <ar...@apache.org>.
sorry, missing part of a sentence.
> Hi Tino,
>
> Tino Schöllhorn wrote:
>
>> Hi Jakob,
>>
>> it would be great if you could integrate it. Where exactly the element
>> is removed from the collection I do not know either. I'd thought you
>> could help here. But anyway: if the modified code is checked in it
>> works great and should'nt have any side effects.
>>
>
> Think we need an test case to reproduce your test. Could you modify an
> existing test (e.g. using CollectionTests) to reproduce your problem?
>
> As PB-api is not thread-safe (each thread have to use it's own PB
> instance)
and your test is a single threaded one,
> the error could only happen when OJB itself try to remove an
> object from the Iterator. If this is the case OJB has a bug in handling
> deleted objects and should be fixed IMO without copy the referenced
> objects (if this will not be possible, your patch should be applied).
>
> regards,
> Armin
>
>
>> With regards
>> Tino
>>
>>
>>
>> Jakob Braeuchi wrote:
>>
>>> hit tino, chris,
>>>
>>> i can integrate your patch into delteCollections(), but i still do
>>> not see
>>> where the element is removed from the collection. doDelete() deletes the
>>> item from the db.
>>>
>>> jakob
>>>
>>>
>>>> Hi Chris,
>>>>
>>>> you're absolutely right and exactly that happens in the
>>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>>> that not every Iterator-type supports the remove method. So I
>>>> proposed a patch that works even if the used Iterator doesn't support
>>>> Iterator#remove.
>>>>
>>>> With regards
>>>> Tino
>>>>
>>>> Chris Lamprecht wrote:
>>>>
>>>>> It can happen with two threads, but it can also happen in this
>>>>> situation (which I've seen several times):
>>>>>
>>>>> Iterator iterator = myCollection.iterator();
>>>>> while (iterator.hasNext()) {
>>>>> Object foo = iterator.next();
>>>>> if (something is true about foo) {
>>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>>> iterator.remove() instead
>>>>> }
>>>>> }
>>>>>
>>>>> So the mistake is, you can't call remove() on a collection while
>>>>> you're iterating through it -- instead you need to call
>>>>> iterator.remove(), which removes the last object you got from
>>>>> iterator.next(). It won't complain on the call to
>>>>> collection.remove(), but next time you call iterator.next(), it will
>>>>> throw a ConcurrentModificationException.
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>>> <ol...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> Hi Tino,
>>>>>>
>>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>>> will be thrown only when there are two concurrent changes to the same
>>>>>> list. This can only be the case when there are two threads working on
>>>>>> the same collection. How can this happen?
>>>>>>
>>>>>> Can you explain why you think your patch works?
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>>
>>>>>>
>>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>>
>>>>>>
>>>>>>> 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
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: Bug and proposed patch
Posted by Armin Waibel <ar...@apache.org>.
Tino Schöllhorn wrote:
> Hi Armin,
>
> I can reproduce this behavior in a scenario which is single-threaded and
> it uses only one PB.
ok
> For the test case: I will try to provide a test
> case where one can reproduce this behaviour but I think I will need your
> help there: for example I do not know how I can run your existing test
> cases and what db they are using.
if you are using OJB source version then you could run each test case in
your IDE.
1. call "ant prepare-testdb" to setup OJB test bed.
2. Run the test, e.g. CollectionsTest.java in your IDE, set working
directory to ....db-ojb/target/test/ojb
>
> To my proposed fix: I also think that this fix is not very elegant, but
> it works. And I can't find an argument why one should not integrate this
> fix in the 1.0_BRANCH.
>
I would apply your patch as a last resort, because it only mask a more
serious design problem (if you right and there was an bug ;-)).
regards,
Armin
> regards,
> Tino
>
>
> Armin Waibel wrote:
>
>> Hi Tino,
>>
>> Tino Schöllhorn wrote:
>>
>>> Hi Jakob,
>>>
>>> it would be great if you could integrate it. Where exactly the
>>> element is removed from the collection I do not know either. I'd
>>> thought you could help here. But anyway: if the modified code is
>>> checked in it works great and should'nt have any side effects.
>>>
>>
>> Think we need an test case to reproduce your test. Could you modify an
>> existing test (e.g. using CollectionTests) to reproduce your problem?
>>
>> As PB-api is not thread-safe (each thread have to use it's own PB
>> instance) the error could only happen when OJB itself try to remove an
>> object from the Iterator. If this is the case OJB has a bug in
>> handling deleted objects and should be fixed IMO without copy the
>> referenced objects (if this will not be possible, your patch should be
>> applied).
>>
>> regards,
>> Armin
>>
>>
>>> With regards
>>> Tino
>>>
>>>
>>>
>>> Jakob Braeuchi wrote:
>>>
>>>> hit tino, chris,
>>>>
>>>> i can integrate your patch into delteCollections(), but i still do
>>>> not see
>>>> where the element is removed from the collection. doDelete() deletes
>>>> the
>>>> item from the db.
>>>>
>>>> jakob
>>>>
>>>>
>>>>> Hi Chris,
>>>>>
>>>>> you're absolutely right and exactly that happens in the
>>>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>>>> that not every Iterator-type supports the remove method. So I
>>>>> proposed a patch that works even if the used Iterator doesn't support
>>>>> Iterator#remove.
>>>>>
>>>>> With regards
>>>>> Tino
>>>>>
>>>>> Chris Lamprecht wrote:
>>>>>
>>>>>> It can happen with two threads, but it can also happen in this
>>>>>> situation (which I've seen several times):
>>>>>>
>>>>>> Iterator iterator = myCollection.iterator();
>>>>>> while (iterator.hasNext()) {
>>>>>> Object foo = iterator.next();
>>>>>> if (something is true about foo) {
>>>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>>>> iterator.remove() instead
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> So the mistake is, you can't call remove() on a collection while
>>>>>> you're iterating through it -- instead you need to call
>>>>>> iterator.remove(), which removes the last object you got from
>>>>>> iterator.next(). It won't complain on the call to
>>>>>> collection.remove(), but next time you call iterator.next(), it will
>>>>>> throw a ConcurrentModificationException.
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>>>> <ol...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Tino,
>>>>>>>
>>>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>>>> will be thrown only when there are two concurrent changes to the
>>>>>>> same
>>>>>>> list. This can only be the case when there are two threads
>>>>>>> working on
>>>>>>> the same collection. How can this happen?
>>>>>>>
>>>>>>> Can you explain why you think your patch works?
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>>>
>>>>>>>
>>>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
Hi Armin,
I can reproduce this behavior in a scenario which is single-threaded and
it uses only one PB. For the test case: I will try to provide a test
case where one can reproduce this behaviour but I think I will need your
help there: for example I do not know how I can run your existing test
cases and what db they are using.
To my proposed fix: I also think that this fix is not very elegant, but
it works. And I can't find an argument why one should not integrate this
fix in the 1.0_BRANCH.
regards,
Tino
Armin Waibel wrote:
> Hi Tino,
>
> Tino Schöllhorn wrote:
>
>> Hi Jakob,
>>
>> it would be great if you could integrate it. Where exactly the element
>> is removed from the collection I do not know either. I'd thought you
>> could help here. But anyway: if the modified code is checked in it
>> works great and should'nt have any side effects.
>>
>
> Think we need an test case to reproduce your test. Could you modify an
> existing test (e.g. using CollectionTests) to reproduce your problem?
>
> As PB-api is not thread-safe (each thread have to use it's own PB
> instance) the error could only happen when OJB itself try to remove an
> object from the Iterator. If this is the case OJB has a bug in handling
> deleted objects and should be fixed IMO without copy the referenced
> objects (if this will not be possible, your patch should be applied).
>
> regards,
> Armin
>
>
>> With regards
>> Tino
>>
>>
>>
>> Jakob Braeuchi wrote:
>>
>>> hit tino, chris,
>>>
>>> i can integrate your patch into delteCollections(), but i still do
>>> not see
>>> where the element is removed from the collection. doDelete() deletes the
>>> item from the db.
>>>
>>> jakob
>>>
>>>
>>>> Hi Chris,
>>>>
>>>> you're absolutely right and exactly that happens in the
>>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>>> that not every Iterator-type supports the remove method. So I
>>>> proposed a patch that works even if the used Iterator doesn't support
>>>> Iterator#remove.
>>>>
>>>> With regards
>>>> Tino
>>>>
>>>> Chris Lamprecht wrote:
>>>>
>>>>> It can happen with two threads, but it can also happen in this
>>>>> situation (which I've seen several times):
>>>>>
>>>>> Iterator iterator = myCollection.iterator();
>>>>> while (iterator.hasNext()) {
>>>>> Object foo = iterator.next();
>>>>> if (something is true about foo) {
>>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>>> iterator.remove() instead
>>>>> }
>>>>> }
>>>>>
>>>>> So the mistake is, you can't call remove() on a collection while
>>>>> you're iterating through it -- instead you need to call
>>>>> iterator.remove(), which removes the last object you got from
>>>>> iterator.next(). It won't complain on the call to
>>>>> collection.remove(), but next time you call iterator.next(), it will
>>>>> throw a ConcurrentModificationException.
>>>>>
>>>>> -Chris
>>>>>
>>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>>> <ol...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> Hi Tino,
>>>>>>
>>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>>> will be thrown only when there are two concurrent changes to the same
>>>>>> list. This can only be the case when there are two threads working on
>>>>>> the same collection. How can this happen?
>>>>>>
>>>>>> Can you explain why you think your patch works?
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>>
>>>>>>
>>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>>
>>>>>>
>>>>>>> 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
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Bug and proposed patch
Posted by Armin Waibel <ar...@apache.org>.
Hi Tino,
Tino Schöllhorn wrote:
> Hi Jakob,
>
> it would be great if you could integrate it. Where exactly the element
> is removed from the collection I do not know either. I'd thought you
> could help here. But anyway: if the modified code is checked in it works
> great and should'nt have any side effects.
>
Think we need an test case to reproduce your test. Could you modify an
existing test (e.g. using CollectionTests) to reproduce your problem?
As PB-api is not thread-safe (each thread have to use it's own PB
instance) the error could only happen when OJB itself try to remove an
object from the Iterator. If this is the case OJB has a bug in handling
deleted objects and should be fixed IMO without copy the referenced
objects (if this will not be possible, your patch should be applied).
regards,
Armin
> With regards
> Tino
>
>
>
> Jakob Braeuchi wrote:
>
>> hit tino, chris,
>>
>> i can integrate your patch into delteCollections(), but i still do not
>> see
>> where the element is removed from the collection. doDelete() deletes the
>> item from the db.
>>
>> jakob
>>
>>
>>> Hi Chris,
>>>
>>> you're absolutely right and exactly that happens in the
>>> PersistenceBrokerImpl#doDelete method. The tricky thing is though
>>> that not every Iterator-type supports the remove method. So I
>>> proposed a patch that works even if the used Iterator doesn't support
>>> Iterator#remove.
>>>
>>> With regards
>>> Tino
>>>
>>> Chris Lamprecht wrote:
>>>
>>>> It can happen with two threads, but it can also happen in this
>>>> situation (which I've seen several times):
>>>>
>>>> Iterator iterator = myCollection.iterator();
>>>> while (iterator.hasNext()) {
>>>> Object foo = iterator.next();
>>>> if (something is true about foo) {
>>>> myCollection.remove(foo); // INCORRECT! Must call
>>>> iterator.remove() instead
>>>> }
>>>> }
>>>>
>>>> So the mistake is, you can't call remove() on a collection while
>>>> you're iterating through it -- instead you need to call
>>>> iterator.remove(), which removes the last object you got from
>>>> iterator.next(). It won't complain on the call to
>>>> collection.remove(), but next time you call iterator.next(), it will
>>>> throw a ConcurrentModificationException.
>>>>
>>>> -Chris
>>>>
>>>> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>>> <ol...@gmail.com> wrote:
>>>>
>>>>
>>>>> Hi Tino,
>>>>>
>>>>> I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>> will be thrown only when there are two concurrent changes to the same
>>>>> list. This can only be the case when there are two threads working on
>>>>> the same collection. How can this happen?
>>>>>
>>>>> Can you explain why you think your patch works?
>>>>>
>>>>> Oliver
>>>>>
>>>>> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>>
>>>>>
>>>>> <t....@plattform-gmbh.de> wrote:
>>>>>
>>>>>
>>>>>> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
Hi Jakob,
it would be great if you could integrate it. Where exactly the element
is removed from the collection I do not know either. I'd thought you
could help here. But anyway: if the modified code is checked in it works
great and should'nt have any side effects.
With regards
Tino
Jakob Braeuchi wrote:
> hit tino, chris,
>
> i can integrate your patch into delteCollections(), but i still do not see
> where the element is removed from the collection. doDelete() deletes the
> item from the db.
>
> jakob
>
>
>>Hi Chris,
>>
>>you're absolutely right and exactly that happens in the
>>PersistenceBrokerImpl#doDelete method. The tricky thing is though that
>>not every Iterator-type supports the remove method. So I proposed a
>>patch that works even if the used Iterator doesn't support
>>Iterator#remove.
>>
>>With regards
>>Tino
>>
>>Chris Lamprecht wrote:
>>
>>>It can happen with two threads, but it can also happen in this
>>>situation (which I've seen several times):
>>>
>>>Iterator iterator = myCollection.iterator();
>>>while (iterator.hasNext()) {
>>> Object foo = iterator.next();
>>> if (something is true about foo) {
>>> myCollection.remove(foo); // INCORRECT! Must call
>>>iterator.remove() instead
>>> }
>>>}
>>>
>>>So the mistake is, you can't call remove() on a collection while
>>>you're iterating through it -- instead you need to call
>>>iterator.remove(), which removes the last object you got from
>>>iterator.next(). It won't complain on the call to
>>>collection.remove(), but next time you call iterator.next(), it will
>>>throw a ConcurrentModificationException.
>>>
>>>-Chris
>>>
>>>On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
>>><ol...@gmail.com> wrote:
>>>
>>>
>>>>Hi Tino,
>>>>
>>>>I am a newbie to OJB, but AFAIK a concurrent modification exception
>>>>will be thrown only when there are two concurrent changes to the same
>>>>list. This can only be the case when there are two threads working on
>>>>the same collection. How can this happen?
>>>>
>>>>Can you explain why you think your patch works?
>>>>
>>>>Oliver
>>>>
>>>>On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>>>
>>>>
>>>><t....@plattform-gmbh.de> wrote:
>>>>
>>>>
>>>>>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
Re: Bug and proposed patch
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hit tino, chris,
i can integrate your patch into delteCollections(), but i still do not see
where the element is removed from the collection. doDelete() deletes the
item from the db.
jakob
> Hi Chris,
>
> you're absolutely right and exactly that happens in the
> PersistenceBrokerImpl#doDelete method. The tricky thing is though that
> not every Iterator-type supports the remove method. So I proposed a
> patch that works even if the used Iterator doesn't support
> Iterator#remove.
>
> With regards
> Tino
>
> Chris Lamprecht wrote:
> > It can happen with two threads, but it can also happen in this
> > situation (which I've seen several times):
> >
> > Iterator iterator = myCollection.iterator();
> > while (iterator.hasNext()) {
> > Object foo = iterator.next();
> > if (something is true about foo) {
> > myCollection.remove(foo); // INCORRECT! Must call
> > iterator.remove() instead
> > }
> > }
> >
> > So the mistake is, you can't call remove() on a collection while
> > you're iterating through it -- instead you need to call
> > iterator.remove(), which removes the last object you got from
> > iterator.next(). It won't complain on the call to
> > collection.remove(), but next time you call iterator.next(), it will
> > throw a ConcurrentModificationException.
> >
> > -Chris
> >
> > On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
> > <ol...@gmail.com> wrote:
> >
> >>Hi Tino,
> >>
> >>I am a newbie to OJB, but AFAIK a concurrent modification exception
> >>will be thrown only when there are two concurrent changes to the same
> >>list. This can only be the case when there are two threads working on
> >>the same collection. How can this happen?
> >>
> >>Can you explain why you think your patch works?
> >>
> >>Oliver
> >>
> >>On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
> >>
> >>
> >><t....@plattform-gmbh.de> wrote:
> >>
> >>>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
>
--
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Bug and proposed patch
Posted by Tino Schöllhorn <t....@plattform-gmbh.de>.
Hi Chris,
you're absolutely right and exactly that happens in the
PersistenceBrokerImpl#doDelete method. The tricky thing is though that
not every Iterator-type supports the remove method. So I proposed a
patch that works even if the used Iterator doesn't support Iterator#remove.
With regards
Tino
Chris Lamprecht wrote:
> It can happen with two threads, but it can also happen in this
> situation (which I've seen several times):
>
> Iterator iterator = myCollection.iterator();
> while (iterator.hasNext()) {
> Object foo = iterator.next();
> if (something is true about foo) {
> myCollection.remove(foo); // INCORRECT! Must call
> iterator.remove() instead
> }
> }
>
> So the mistake is, you can't call remove() on a collection while
> you're iterating through it -- instead you need to call
> iterator.remove(), which removes the last object you got from
> iterator.next(). It won't complain on the call to
> collection.remove(), but next time you call iterator.next(), it will
> throw a ConcurrentModificationException.
>
> -Chris
>
> On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
> <ol...@gmail.com> wrote:
>
>>Hi Tino,
>>
>>I am a newbie to OJB, but AFAIK a concurrent modification exception
>>will be thrown only when there are two concurrent changes to the same
>>list. This can only be the case when there are two threads working on
>>the same collection. How can this happen?
>>
>>Can you explain why you think your patch works?
>>
>>Oliver
>>
>>On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>>
>>
>><t....@plattform-gmbh.de> wrote:
>>
>>>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
Re: Bug and proposed patch
Posted by Chris Lamprecht <cl...@gmail.com>.
It can happen with two threads, but it can also happen in this
situation (which I've seen several times):
Iterator iterator = myCollection.iterator();
while (iterator.hasNext()) {
Object foo = iterator.next();
if (something is true about foo) {
myCollection.remove(foo); // INCORRECT! Must call
iterator.remove() instead
}
}
So the mistake is, you can't call remove() on a collection while
you're iterating through it -- instead you need to call
iterator.remove(), which removes the last object you got from
iterator.next(). It won't complain on the call to
collection.remove(), but next time you call iterator.next(), it will
throw a ConcurrentModificationException.
-Chris
On Mon, 13 Dec 2004 00:20:15 +0100, Oliver Zeigermann
<ol...@gmail.com> wrote:
> Hi Tino,
>
> I am a newbie to OJB, but AFAIK a concurrent modification exception
> will be thrown only when there are two concurrent changes to the same
> list. This can only be the case when there are two threads working on
> the same collection. How can this happen?
>
> Can you explain why you think your patch works?
>
> Oliver
>
> On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
>
>
> <t....@plattform-gmbh.de> wrote:
> > 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
Re: Bug and proposed patch
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi Tino,
I am a newbie to OJB, but AFAIK a concurrent modification exception
will be thrown only when there are two concurrent changes to the same
list. This can only be the case when there are two threads working on
the same collection. How can this happen?
Can you explain why you think your patch works?
Oliver
On Sun, 12 Dec 2004 12:13:48 +0100, Tino Schöllhorn
<t....@plattform-gmbh.de> wrote:
> 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