axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: [Axis2]Add clone method to axis2_property
Date Fri, 24 Nov 2006 10:04:28 GMT
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 
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. 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.


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

View raw message