At IDE, we encountered scalability problems with the Logging Service due to the persistence strategy API.

Currently, the Logging Service uses a ACE_SYNC_RW_MUTEX as a lock around all operations.  This generally worked well, as logging new records needed to be serialized anyway.  However, we discovered that rwlocks were not "fair". On some platforms, a thread could be blocked indefinitely while others received and then processed new log messages.  In the IDE repo, I changed the log to a ACE_Token, which addressed this problem.

A larger problem, which I did not have time to resolve, was that a long running query() (or match(), or similar operation) essentially blocked the log service from recording new log messages.

This suggests the logging service needs more than a simple change of logging primitive, but rather to use a transactional semantics that will allow simultaneous inserts and queries.

This may be difficult to do for the default strategy, but it's concrete "transaction" object could simply wrap a rwlock or token with no loss or benefit.  But dynamically loaded strategies that use a RDBMS back end, could use native transactions and would benefit from the added concurrency and scalability.