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 Jamie Burns <ja...@hotmail.com> on 2003/02/25 00:54:11 UTC
Fix for bug in PersistenceBrokerImpl (Part 1)
Hi.
I found what l believe to be a bug in PersistenceBrokerImpl.
I have an EpisodeDetails object which has a collection of LegalSituations in an indirection table EpsDetLegSit. When a user deletes an EpsDetLegSit it is removed ok when the transaction is committed. However, if they try to add the EpsDetLegSit back in in the same VM it does not get added when the transaction is committed.
Back in November last year (2002/11/11) a change was made to the setInitialModificationState method in ObjectEnvelope. The change looked in a Map maintained by LoadedObjectsRegistry to see if the object had already been loaded in the VM. If the Map contained the object, ObjectEnvelope sets the initial state to StateOldClean. This is ok initially, but if the object is deleted it is not removed from LoadedObjectsRegistry. When the user tries to re-add the object, ObjectEnvelope still thinks the object exists and sets the state of the NEW object to StateOldClean.
The changes l am submitting remove entries from the LoadedObjectsRegistry Map when PersistenceBrokerImpl removes entries from its ObjectCache. (Im sending the files in 2 seperate emails. My emails are getting bounced because of some size restriction)
In the future someone might want to look at whether it is the responsibility of a PersistenceBroker or an ObjectCache to keep the LoadedObjectsRegistry in synch. For now, lve made it the responsibilty of a PersistenceBroker.
Re: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
It'd be *really* nice to reduce PBImpl size !
we could handle all types of references on other classes !
On Fri, 2003-02-28 at 13:56, Jakob Braeuchi wrote:
> hi thomas,
>
> PersistenceBrokerImpl keeps getting bigger and bigger...
> i think we should look for a way to reduce it's size. i was thinking of
> moving the handling of collections into separate classes, so PB only
> deals with single objects.
>
> what do you think ?
>
> jakob
>
> Thomas Mahler wrote:
>
> > Hi Jakob,
> >
> > Jakob Braeuchi wrote:
> >
> >> hi thomas,
> >>
> >> is delete m:n implementors no longer needed in storeCollections ?
> >
> >
> > oops, sorry, I think I made a mistake when merging my local version
> > with the latest changes to PB.
> >
> > The modification in storeCollection is not a part of my fix...
> >
> > I'll correct it.
> >
> > thanks,
> > Thomas
> >
> >
> >> jakob
> >>
> >> Thomas Mahler wrote:
> >>
> >>> fixed it!
> >>> thanks for the patch,
> >>> Thomas
> >>>
> >>> Jamie Burns wrote:
> >>>
> >>>> Hi.
> >>>>
> >>>> I found what l believe to be a bug in PersistenceBrokerImpl.
> >>>>
> >>>> I have an EpisodeDetails object which has a collection of
> >>>> LegalSituations in an indirection table EpsDetLegSit. When a user
> >>>> deletes an EpsDetLegSit it is removed ok when the transaction is
> >>>> committed. However, if they try to add the EpsDetLegSit back in in
> >>>> the same VM it does not get added when the transaction is committed.
> >>>>
> >>>> Back in November last year (2002/11/11) a change was made to the
> >>>> setInitialModificationState method in ObjectEnvelope. The change
> >>>> looked in a Map maintained by LoadedObjectsRegistry to see if the
> >>>> object had already been loaded in the VM. If the Map contained the
> >>>> object, ObjectEnvelope sets the initial state to StateOldClean.
> >>>> This is ok initially, but if the object is deleted it is not
> >>>> removed from LoadedObjectsRegistry. When the user tries to re-add
> >>>> the object, ObjectEnvelope still thinks the object exists and sets
> >>>> the state of the NEW object to StateOldClean.
> >>>>
> >>>> The changes l am submitting remove entries from the
> >>>> LoadedObjectsRegistry Map when PersistenceBrokerImpl removes
> >>>> entries from its ObjectCache. (Im sending the files in 2 seperate
> >>>> emails. My emails are getting bounced because of some size
> >>>> restriction)
> >>>>
> >>>> In the future someone might want to look at whether it is the
> >>>> responsibility of a PersistenceBroker or an ObjectCache to keep the
> >>>> LoadedObjectsRegistry in synch. For now, lve made it the
> >>>> responsibilty of a PersistenceBroker.
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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
>
>
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e Servicos (IB)
http://www.ibnetwork.com.br
http://jakarta.apache.org/ojb
Re: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Thomas Mahler <th...@web.de>.
Hi Jakob,
Jakob Braeuchi wrote:
> hi thomas,
>
> PersistenceBrokerImpl keeps getting bigger and bigger...
You are right. I remember times when the file was only 300 LOC or so...
It's now really much bigger than any reasonable code metric would recommend!
> i think we should look for a way to reduce it's size.
I absolutely agree! I also had some offline discussion with Armin about
this issue. Armin already introduced a delegate mechanism to use several
auxiliary service classes.
I also started (but never got quite far) to build a little inheritance
hierarchy and to distribute functionality on different classes that form
an inheritance chain.
(The idea to split the event mechanism in an abstract base class is a
sample for this strategy).
> i was thinking of
> moving the handling of collections into separate classes, so PB only
> deals with single objects.
could be one approach.
It could be also a solution to use separate delagate classes that are
responsible for certain groups of functionality, say:
- loading
- inserting
- updating
- deleting
- transaction handling
- cache handling
maybe this approach is easier to understand (in sense of code reading)
than to pull out reference and collection stuff.
But I have no real preference right now. What do the other developers think?
> what do you think ?
I'm +1 to work on such a refactoring.
"Unser Dorf soll schoener werden!"
cheers,
thomas
>
> jakob
>
> Thomas Mahler wrote:
>
>> Hi Jakob,
>>
>> Jakob Braeuchi wrote:
>>
>>> hi thomas,
>>>
>>> is delete m:n implementors no longer needed in storeCollections ?
>>
>>
>>
>> oops, sorry, I think I made a mistake when merging my local version
>> with the latest changes to PB.
>>
>> The modification in storeCollection is not a part of my fix...
>>
>> I'll correct it.
>>
>> thanks,
>> Thomas
>>
>>
>>> jakob
>>>
>>> Thomas Mahler wrote:
>>>
>>>> fixed it!
>>>> thanks for the patch,
>>>> Thomas
>>>>
>>>> Jamie Burns wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> I found what l believe to be a bug in PersistenceBrokerImpl.
>>>>>
>>>>> I have an EpisodeDetails object which has a collection of
>>>>> LegalSituations in an indirection table EpsDetLegSit. When a user
>>>>> deletes an EpsDetLegSit it is removed ok when the transaction is
>>>>> committed. However, if they try to add the EpsDetLegSit back in in
>>>>> the same VM it does not get added when the transaction is committed.
>>>>>
>>>>> Back in November last year (2002/11/11) a change was made to the
>>>>> setInitialModificationState method in ObjectEnvelope. The change
>>>>> looked in a Map maintained by LoadedObjectsRegistry to see if the
>>>>> object had already been loaded in the VM. If the Map contained the
>>>>> object, ObjectEnvelope sets the initial state to StateOldClean.
>>>>> This is ok initially, but if the object is deleted it is not
>>>>> removed from LoadedObjectsRegistry. When the user tries to re-add
>>>>> the object, ObjectEnvelope still thinks the object exists and sets
>>>>> the state of the NEW object to StateOldClean.
>>>>>
>>>>> The changes l am submitting remove entries from the
>>>>> LoadedObjectsRegistry Map when PersistenceBrokerImpl removes
>>>>> entries from its ObjectCache. (Im sending the files in 2 seperate
>>>>> emails. My emails are getting bounced because of some size
>>>>> restriction)
>>>>>
>>>>> In the future someone might want to look at whether it is the
>>>>> responsibility of a PersistenceBroker or an ObjectCache to keep the
>>>>> LoadedObjectsRegistry in synch. For now, lve made it the
>>>>> responsibilty of a PersistenceBroker.
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas,
PersistenceBrokerImpl keeps getting bigger and bigger...
i think we should look for a way to reduce it's size. i was thinking of
moving the handling of collections into separate classes, so PB only
deals with single objects.
what do you think ?
jakob
Thomas Mahler wrote:
> Hi Jakob,
>
> Jakob Braeuchi wrote:
>
>> hi thomas,
>>
>> is delete m:n implementors no longer needed in storeCollections ?
>
>
> oops, sorry, I think I made a mistake when merging my local version
> with the latest changes to PB.
>
> The modification in storeCollection is not a part of my fix...
>
> I'll correct it.
>
> thanks,
> Thomas
>
>
>> jakob
>>
>> Thomas Mahler wrote:
>>
>>> fixed it!
>>> thanks for the patch,
>>> Thomas
>>>
>>> Jamie Burns wrote:
>>>
>>>> Hi.
>>>>
>>>> I found what l believe to be a bug in PersistenceBrokerImpl.
>>>>
>>>> I have an EpisodeDetails object which has a collection of
>>>> LegalSituations in an indirection table EpsDetLegSit. When a user
>>>> deletes an EpsDetLegSit it is removed ok when the transaction is
>>>> committed. However, if they try to add the EpsDetLegSit back in in
>>>> the same VM it does not get added when the transaction is committed.
>>>>
>>>> Back in November last year (2002/11/11) a change was made to the
>>>> setInitialModificationState method in ObjectEnvelope. The change
>>>> looked in a Map maintained by LoadedObjectsRegistry to see if the
>>>> object had already been loaded in the VM. If the Map contained the
>>>> object, ObjectEnvelope sets the initial state to StateOldClean.
>>>> This is ok initially, but if the object is deleted it is not
>>>> removed from LoadedObjectsRegistry. When the user tries to re-add
>>>> the object, ObjectEnvelope still thinks the object exists and sets
>>>> the state of the NEW object to StateOldClean.
>>>>
>>>> The changes l am submitting remove entries from the
>>>> LoadedObjectsRegistry Map when PersistenceBrokerImpl removes
>>>> entries from its ObjectCache. (Im sending the files in 2 seperate
>>>> emails. My emails are getting bounced because of some size
>>>> restriction)
>>>>
>>>> In the future someone might want to look at whether it is the
>>>> responsibility of a PersistenceBroker or an ObjectCache to keep the
>>>> LoadedObjectsRegistry in synch. For now, lve made it the
>>>> responsibilty of a PersistenceBroker.
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Thomas Mahler <th...@web.de>.
Hi Jakob,
Jakob Braeuchi wrote:
> hi thomas,
>
> is delete m:n implementors no longer needed in storeCollections ?
oops, sorry, I think I made a mistake when merging my local version with
the latest changes to PB.
The modification in storeCollection is not a part of my fix...
I'll correct it.
thanks,
Thomas
> jakob
>
> Thomas Mahler wrote:
>
>> fixed it!
>> thanks for the patch,
>> Thomas
>>
>> Jamie Burns wrote:
>>
>>> Hi.
>>>
>>> I found what l believe to be a bug in PersistenceBrokerImpl.
>>>
>>> I have an EpisodeDetails object which has a collection of
>>> LegalSituations in an indirection table EpsDetLegSit. When a user
>>> deletes an EpsDetLegSit it is removed ok when the transaction is
>>> committed. However, if they try to add the EpsDetLegSit back in in
>>> the same VM it does not get added when the transaction is committed.
>>>
>>> Back in November last year (2002/11/11) a change was made to the
>>> setInitialModificationState method in ObjectEnvelope. The change
>>> looked in a Map maintained by LoadedObjectsRegistry to see if the
>>> object had already been loaded in the VM. If the Map contained the
>>> object, ObjectEnvelope sets the initial state to StateOldClean. This
>>> is ok initially, but if the object is deleted it is not removed from
>>> LoadedObjectsRegistry. When the user tries to re-add the object,
>>> ObjectEnvelope still thinks the object exists and sets the state of
>>> the NEW object to StateOldClean.
>>>
>>> The changes l am submitting remove entries from the
>>> LoadedObjectsRegistry Map when PersistenceBrokerImpl removes entries
>>> from its ObjectCache. (Im sending the files in 2 seperate emails. My
>>> emails are getting bounced because of some size restriction)
>>>
>>> In the future someone might want to look at whether it is the
>>> responsibility of a PersistenceBroker or an ObjectCache to keep the
>>> LoadedObjectsRegistry in synch. For now, lve made it the
>>> responsibilty of a PersistenceBroker.
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas,
is delete m:n implementors no longer needed in storeCollections ?
jakob
Thomas Mahler wrote:
> fixed it!
> thanks for the patch,
> Thomas
>
> Jamie Burns wrote:
>
>> Hi.
>>
>> I found what l believe to be a bug in PersistenceBrokerImpl.
>>
>> I have an EpisodeDetails object which has a collection of
>> LegalSituations in an indirection table EpsDetLegSit. When a user
>> deletes an EpsDetLegSit it is removed ok when the transaction is
>> committed. However, if they try to add the EpsDetLegSit back in in
>> the same VM it does not get added when the transaction is committed.
>>
>> Back in November last year (2002/11/11) a change was made to the
>> setInitialModificationState method in ObjectEnvelope. The change
>> looked in a Map maintained by LoadedObjectsRegistry to see if the
>> object had already been loaded in the VM. If the Map contained the
>> object, ObjectEnvelope sets the initial state to StateOldClean. This
>> is ok initially, but if the object is deleted it is not removed from
>> LoadedObjectsRegistry. When the user tries to re-add the object,
>> ObjectEnvelope still thinks the object exists and sets the state of
>> the NEW object to StateOldClean.
>>
>> The changes l am submitting remove entries from the
>> LoadedObjectsRegistry Map when PersistenceBrokerImpl removes entries
>> from its ObjectCache. (Im sending the files in 2 seperate emails. My
>> emails are getting bounced because of some size restriction)
>>
>> In the future someone might want to look at whether it is the
>> responsibility of a PersistenceBroker or an ObjectCache to keep the
>> LoadedObjectsRegistry in synch. For now, lve made it the
>> responsibilty of a PersistenceBroker.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
Re: Fix for bug in PersistenceBrokerImpl (Part 1)
Posted by Thomas Mahler <th...@web.de>.
fixed it!
thanks for the patch,
Thomas
Jamie Burns wrote:
> Hi.
>
> I found what l believe to be a bug in PersistenceBrokerImpl.
>
> I have an EpisodeDetails object which has a collection of LegalSituations in an indirection table EpsDetLegSit. When a user deletes an EpsDetLegSit it is removed ok when the transaction is committed. However, if they try to add the EpsDetLegSit back in in the same VM it does not get added when the transaction is committed.
>
> Back in November last year (2002/11/11) a change was made to the setInitialModificationState method in ObjectEnvelope. The change looked in a Map maintained by LoadedObjectsRegistry to see if the object had already been loaded in the VM. If the Map contained the object, ObjectEnvelope sets the initial state to StateOldClean. This is ok initially, but if the object is deleted it is not removed from LoadedObjectsRegistry. When the user tries to re-add the object, ObjectEnvelope still thinks the object exists and sets the state of the NEW object to StateOldClean.
>
> The changes l am submitting remove entries from the LoadedObjectsRegistry Map when PersistenceBrokerImpl removes entries from its ObjectCache. (Im sending the files in 2 seperate emails. My emails are getting bounced because of some size restriction)
>
> In the future someone might want to look at whether it is the responsibility of a PersistenceBroker or an ObjectCache to keep the LoadedObjectsRegistry in synch. For now, lve made it the responsibilty of a PersistenceBroker.
>