SetPrefetch vs UseConcurrencyLimit

[Tomer Yoskovich]

Hello,

I understand that Prefetch is for all message types defined on the queue and concurrency limit is for specific type.

This feature is very important for the messages that are directed to an automatonymous saga::

1) we want multiple sagas to be able to run concurrently

2) but we don't want the same saga instance to exist twice, handling the 2 messages with conflicting DB persistence issues etc.

So having a high prefetch, and concurrency level of 1 should do the trick

I'm wondering about how does the concurrency limit work?

since it is reading from a queue, it means that it must do something with the message in order to get to the next message (which may be related to another saga instance and thus should be run). So my guess is that it is simply consuming the message, leaving it in memory, and not sending an ACK to rabbitMQ for that message.

my question is based on what's described here : http://docs.masstransit-project.com/en/latest/overview/underthehood.html#faq

Is it how it really works?
Thanks

[Chris Patterson]

For the most part it is correct, but there are some details omitted. 

Messages are pushed from the broker to MassTransit. The prefetch count is the number of unacknowledged messages which are allowed to be pushed to MassTransit. When the prefetch count is reached, the broker will stop pushing messages until one or more messages are acknowledged. 

The concurrency limit works by using a semaphore to limit access to the consumer to a number of concurrent tasks.

With a saga, using a database with pessimistic locks, you can do the same thing since the lock in the database will prevent two instances from running at the same time if they have the same CorrelationId specified. If you are seeing locks or deadlocks, you can use the PreInsert and saga factory to build and save your saga instance prior to the first event being processed by it. This will do a true insert instead of a select/lock/insert which is better when using a serializable isolation level - which is required for proper locking. 

The concurrency limit is per receive endpoint, so if you have two machines running the same service on the same queue, you'll need to use database level locking or some other strategy to limit concurrency per saga instance to one. 

__
Chris Patterson

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/ed59812e-737f-41c0-b693-586382bffa1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.