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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
