axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damitha Kumarage <>
Subject Re: [Axis2]Add clone method to axis2_property
Date Thu, 30 Nov 2006 04:31:45 GMT
Samisa Abeysinghe wrote:

> Damitha Kumarage wrote:
>> Samisa Abeysinghe wrote:
>>> Dinesh Premalal wrote:
>>>> Hi,
>>>> Damitha Kumarage <> writes:
>>>>> Hi,
>>>>> We copy properties from one ctx to another ctx often(in sandesha2 
>>>>> also)
>>>>> This lead to problems in Sandesha2.
>>>>> To avoid this would like to add a clone function ot axis2_property
>>>>> like we have done in
>>>>> aixs2_qname.
>>>> If we can maintain a reference counter, we could be able to get rid of
>>>> double freeing etc. Every time you referencing to that property
>>>> reference counter increases. Reference counter decrements when
>>>> freeing. Actual Freeing occurred when reference counter reaches to 0.
>>>> I think this method will be less expensive than cloning.   
>>> Ref count solved the problem but increases coupling. It becomes hard 
>>> to use it with all the places needing a reference having to deal 
>>> with ref count.
>> But it seems we have to keep a reference count.  Otherwise it is 
>> impossible to create a new context using exising context.
>> So it seems that we need to add an add_ref function to 
>> aixs2_property. As Dinesh said when axis2_property_free is called
>> this ref count is decreased by 1 and when it is 0 actual freeding 
>> should happen
> When are we going to increase the ref count? In which methods? I think 
> we have to be clear on this, before implementing ref count. Unlike in 
> the case of namespaces, where the use is limited, properties are more 
> widely used - so IMHO, maintaining the ref count itself would be a 
> headache.
> P.S. Even with namespace ref count, I am facing problems where there 
> is a leak in client failure cases - but I still cannot figure out 
> where the leak is happening. It sure help in some situations, but not 
> at all times.
> The other solution is to  use the scope concept of the property.  For 
> the  properties that  we copy  across,  we can set the scope to  be  
> application, in which case they are not freed by message context.

Currently I use this and it works fine. Actually when I look into the 
whole code I can see that no structs except strings are set to 
properties from client api's level. In all other places where structs 
are set as property values I see that the scope is application level. 
When scope is application level usually the value is not freed by the 
property but by some other owner of the struct. So what I'm going to 
suggest is not to free property values at property level at all. AFAIK 
this will not affect
the current code. In fututre also we can avoid that. This will save us 
from lot of headache.
Also even if we free property values the scope in the property has no 
meaning. It should be a boolean to indicate whether
to free the value or not(May be I was the one who indroduced it to the 
property :)). Because scope of the property can
be understood by to which struct it belongs to(ex. a conf property is 
application scope above is more natural.

> We can also set them at a higher level of the context hierarchy other 
> than message context, however, that is not possible if the properties 
> message level properties (that is each massage has a unique property 
> value), but the requirement suggests otherwise. Please see if that 
> Would be a viable solution. Else we may have to live with ref-count.
> Samisa...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message