Why sagarepository is recommended to have Serializable isolation level?

[Roman Prykhodko]

Hi. 

We have postgress database with Serializable isolation level of saga repository. When repository reads saga state, all saga table is blocked for adding and editing. It causes concurrence error "could not serialize access due to read/write dependencies among transactions" occuring many times. Retrys help, but it takes too many attampts, slows down the software and faults happen periodically. When isolation level is reduced to Repeatable Read, error doesn't occur at all. May we use Repeatable Read instead of Serializable? is it safe for automatonymous? Or Serializable is the only option? 

[Chris Patterson]

The saga repository depends upon an exclusive row-level lock on the saga instance, in order to enforce only a single instance of the saga being processed a given time. It all depends upon your saga, and how it's handled, as well as the locking method you're using, to decide which mode is right for you.

On Wed, Dec 26, 2018 at 12:32 AM Roman Prykhodko <prykhod...@gmail.com> wrote:

Hi. 

We have postgress database with Serializable isolation level of saga repository. When repository reads saga state, all saga table is blocked for adding and editing. It causes concurrence error "could not serialize access due to read/write dependencies among transactions" occuring many times. Retrys help, but it takes too many attampts, slows down the software and faults happen periodically. When isolation level is reduced to Repeatable Read, error doesn't occur at all. May we use Repeatable Read instead of Serializable? is it safe for automatonymous? Or Serializable is the only option? 

--
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/d1e814f1-d2d3-4aae-a37a-719ad268c061%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexey Zimarev]

The easiest level to ensure high throughput is to use optimistic concurrency. Both EF and NHibernate saga persistence providers support it. When the optimistic concurrency is used, the lock becomes less relevant, but you get a chance to get retries for the same instance in case of multiple messages being consumed for the same saga instance at the same time. So, trade-offs, choose your poison...