MOM and distributed cache are popular in trading apps. Developers tend to shy away from DB due to latency. However, for rapid development, relational DB offers excellent debugging, tracing, and correlation capabilities in a context of event-driven, callback-driven, concurrent processing. When things fail mysteriously and intermittently, logging is the key, but u often have multiple log files. You can query the cache but much less easily than DB.
Important events can be logged in DB tables and
* joined (#1 most powerful)
* searched in complex ways
* log data-mining. We can discover baselines, trends and anti-trends.
* Log files are usually archived (less accessible) and then removed, but DB data are usually more permanent. Don't ask me why:)
* selectively delete log events, easily, quickly.
* Data can be transformed.
* accessible by web service
* concurrent access
* extracted into another, more usable table.
* More powerful than XML.
Perhaps the biggest logistical advantage of DB is easy availability. Most applications can access the DB.
Adding db-logging requires careful design. When time to market is priority, I feel the debug capability of DB can be a justification for the effort.
A GS senior manager preferred logging in DB. Pershing developers generally prefer searching the same data in DB rather than file.