Axon View Updates Clarifications

I have been having this discussion with my colleagues and so I need some clarification. We’ve been having issues with transactions failing because of timeout, as a lot of processes are trying to update the same table. That is why the event sourcing looked like a way out to us. But we were having this argument; since tables are still being updated, does it not bring us back to the same problem we currently face? Please correct me if I misunderstood something:

  1. When commands are sent from the UI an event is generated and stored. Then axon token tracker updates the views at its own pace(eventual consistency).
    So let’s say I have thousands of events getting to the event store every minute, does the event store have any contention on inserts? Does it fail sometimes?

  2. Since its axon that manages the projected table updates, from what I understand, it means there will never be a case where an update failed because of timeout, waiting for another update to get through, because axon manages that using the event store which is some sort of a queue.

Hi Harvey,

I assume these timeouts occur in a “traditional” application, where a single data model is used for both queries and updates?
If that is the case, yes, this architectural style will definitely reduce (and most likely eliminate) these types of timeouts. The cause of these timeouts are most likely deadlocks caused by processes that obtain a read lock first, and then attempt to upgrade their lock to a write lock (to update).

Hope this helps.
Cheers,

Allard

Thanks Allard. I stll have a doubt to clear.
From the axon-trader implementations I’ve seen, the projection is queried to get the row to update, then saved again. So how is the situation different? Could you explain where the performance gain is situated?

Hi Harvey,

if there would be a locking issue in that application (which could happen under stress), you could easily solve that by requesting a read-lock on the read. Since it’s a read to update, that would actually be the best to do.

Cheers,

Allard