Doing some benchmarking of my app, I found a place where I think Axon could cut down on the number of database queries it issues, but it’d require a small API change to the saga repository.
As background, my app has a fairly large number of saga classes many of which have handlers for a handful of common application-wide events. It’s running on PostgreSQL with the JDBC repository.
Right now when one of those events is published, Axon loops through each saga class that has an event handler for it and calls SagaSqlSchema.sql_findAssocSagaIdentifiers() for each one to see if there are any active saga instances associated with the event’s values. This results in a lot of empty result sets (since most of the app’s saga classes aren’t interested in most instances of a given event) and a sizable amount of time spent making database queries. Individually these queries are very fast since the table has proper indexes, but they add up.
If sql_findAssocSagaIdentifiers() were passed a collection of saga types, rather than a single saga type, it could use WHERE sagaType IN (…) to find all the matching sagas in one database round-trip for any arbitrary number of saga classes. That would result in fewer queries whenever there’s more than one saga class interested in a particular event, and worst case would be no worse than the existing behavior.
Similarly (though much less important), the association value cache could change from “(saga type, key, value) -> Set(saga ID)” to “(key, value) -> Map(saga type, Set(saga ID))” to cut down on cache churn; right now our cache is dominated by empty sets of saga IDs.
Does this idea make sense?
-Steve
P.S. Apologies if this is a duplicate; Google gave me a somewhat ambiguous error message when I tried to send it to the group the first time.