![]() This issue is common and can be solved by postponing the message publish and send operations until all persistence work is done. Or, if there are no retry policies configured, messages might be sent indicating that the process needs to continue but saga instance will be in the old state and will not accept any further messages because they will come in a wrong state. MassTransit will eventually use retry policy on the endpoint and more messages will be send, potentially leading to mess. It is normal for the saga repository to throw an exception in such case but if your saga is publishing messages, they were already published but the saga state has not been updated. All those problems are basically saying that you are having a concurrency issue. ![]() Depending on the saga repository type, this might fail for different reasons - versioning issue, row or table lock or eTag mismatch. This means that there could be more than one saga state updates that are being persisted at the same time. However, if your saga received a lot of messages coming roughly at the same time and the endpoint is set to process multiple messages in parallel - this can lead to a conflict between message processing and saga persistence. Sagas are completely message-driven and therefore not only consume but also publish events and send commands. This will enable better concurrency handling and will make the saga state consistent. It is strongly advised to have CorrelationId as your table/document key. Seriously, don't sent an event to all instances - unless you want to watch your messages consumers lock your entire saga storage engine. With a correlation expression, the expression might match to more than one saga instance, so care should be used - because the event would be delivered to all matching instances. If the CorrelationId is used, it's always a one-to-one match, either the saga already exists, or it's a new saga instance. Events are correlated to the saga instance using either the unique identifier, or alternatively using an expression that correlates properties on the saga instance to each event. Saga instances are identified by a unique identifier ( Guid), represented by the CorrelationId on the saga instance. Of course, in-memory repository supports it as well. Repository implementation such as Entity Framework, NHibernate and Marten support correlation by query. Such correlations are defined using CorrelateBy method and you can use any logical expression that involve the event data and saga state data to establish such correlation. Query repository by definition support identity correlation too, but in addition support other properties of events being received and saga state properties. This means that all events that the saga receives, must hold the saga correlation id, and the correlation for each event can only use CorrelateById method to define the correlation. When using identity-only repository, such as Azure Service Bus message session or Redis, you can only use correlation by identity. CreateUsingInMemory (x => ) ĭepending on the persistence mechanism, repository implementation can be either identity-only or identity plus query. Var orderStateMachine = new OrderStateMachine ( ) var repository = new InMemorySagaRepository ( ) var busControl = Bus.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |