Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Message-ID: <3E5FAE76.7040209@web.de>
Date: Fri, 28 Feb 2003 19:46:14 +0100
From: Thomas Mahler <thma32@web.de>
Reply-To: thma@apache.org
Organization: Apache Foundation
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020903
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: Fix for bug in PersistenceBrokerImpl (Part 1)
References: <016101c2dc60$07d1b430$0101010a@burns01> <3E5E5AD9.7000300@web.de>
 <3E5E602A.9000709@gmx.ch> <3E5F00AA.1050509@web.de> <3E5F94AF.4060303@gmx.ch>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: thma32@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
> 
>