axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uthaiyashankar <shan...@wso2.com>
Subject Re: Using Apache2 global mutex
Date Wed, 23 Jul 2008 05:41:46 GMT
Hi,

See my comments



>>>
>>> Suppose  two requests come to Axis2/C sequentially. Say the first 
>>> request is served by one apache process and the next request is 
>>> served by another process. Then problem is you cannot access the 
>>> previous requests configuration context from your next request 
>>> because each process has it's own configuration context. We recently 
>>> solved this problem using shared memory. But as should be expected 
>>> this is extremely inefficient.
>>
>> Yes, it is about 10 times slower than non-shared memory implementation.
>>
>>>
>>> The other and more effiecient solution is using a database that 
>>> could be shared among your processes. Sandesha2/C uses this approach. 
>>
>> We have to test the performance of this to decide whether it is worth
>> doing. I guess the performance will be higher than shared memory
>> implementation. Only problem is how to solve concurrency issue, without
>> global mutex.
>>
>>
>>> To solve concurrency issues when using this approach we can use 
>>> Apache2 golbal mutex which could be used when accessing global 
>>> resources like system files and databases. 
>>
>> Shared memory implementation is very slow because of global mutex :).
> Since you implemented it and has good understanding I may ask 
> following questions to understand the situation well.
>
> -Did you use apr_shm/apr_rmm or apr_dbm in your implementation?

apr_shm/apr_rmm

>
> -If you used apr_shm/apr_rmm then using apache thread_mutex to protect 
> axis2 contexts is not enough?. AFAIK they are less expensive than 
> global mutexts.

I am not using the global mutex to protect axis2 contexts. It is used to 
protect apr_rmm structures. You have to use global mutex to protect it.

>
> -Is using apr_dbm more expensive?. I guess the answer is yes.

I think it is more expensive.

>
> -In the database option can't we use mod_dbd which manages a pool of 
> database connections efficiently. It is using apr_reslist. Can we use 
> apr_reslist directly without mod_dbd?

I am not sure about this. We can try and see..

Regards,
Shankar

>
> thanks,
> Damitha
>> So, if we introduce it here, then again we are going to have same issue
>> as in shared memory implementation. Can't we have database level
>> concurrency protection to solve this?
>>
>> Shall we have a comparision of database implementation Vs shared memory
>> - with and without global mutex to see whether it is worth doing?
>>
>> Regards,
>> Shankar.
>>
>>> But the problem is how we could pass this global mutext from Axis2 
>>> apache module to be accessible from other parts of the code, for 
>>> example from a Axis2/C module. We currently pass Apache2 pools 
>>> through axis2_env_t environment. How about using the same in passing 
>>> this as well?
>>>
>>> thanks,
>>> Damitha
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message