Ayende @ Rahien

Sergey Shishkin commented on Rhino Service Bus: Concurrency Violations are Business Logic

Mon, 26 Jan 2009 12:59:57 GMT

Rafal, the joy of distributed transactions was the original reason to use DHT and versioning for sagas, afaik.

Rafal commented on Rhino Service Bus: Concurrency Violations are Business Logic

Fri, 23 Jan 2009 08:21:46 GMT

Sergey, if saga persistence is transactional and sending messages is transactional, you can wrap everything in a distributed transaction and enjoy consistent behavior.

Sergey Shishkin commented on Rhino Service Bus: Concurrency Violations are Business Logic

Fri, 23 Jan 2009 08:05:57 GMT

Some things are easier to avoid rather than to compensate their consequences. Imagine you've sent two messages: "customer accepted" and "customer not accepted". Somebody might have reacted already. A possible solution might be to delay delivery of outgoing messages from a saga until the saga is persisted. And if it's inconsistent at that point, just throw the delayed messages away and give the saga an opportunity to send the right message. What do you think?

Ayende Rahien commented on Rhino Service Bus: Concurrency Violations are Business Logic

Thu, 22 Jan 2009 21:33:40 GMT

That is why you have compensating actions.

Sergey Shishkin commented on Rhino Service Bus: Concurrency Violations are Business Logic

Thu, 22 Jan 2009 20:40:37 GMT

I like the idea behind Rhino DHT, but what do you do if 2nd and 3rd score messages arrive simultaneously? Both instances of the saga will send the "accepted" or "not accepted" message (depending on the average scores in both instances). You say that the saga can not complete in an inconsistent state, but what do you do with messages (possibly with opposite results) that already sent?

Ayende Rahien commented on Rhino Service Bus: Concurrency Violations are Business Logic

Thu, 22 Jan 2009 12:14:29 GMT

Rafal, The distribution is based on this model: [ayende.com/.../NServiceBus-Distributor-Review.aspx](http://ayende.com/Blog/archive/2008/03/24/NServiceBus-Distributor-Review.aspx)

Rafal commented on Rhino Service Bus: Concurrency Violations are Business Logic

Thu, 22 Jan 2009 07:34:19 GMT

I think I understand what you want to achieve: a 100% distributed environment with independent nodes processing incoming messages and with no centralized elements. It works nicely when messages are 'additive', but merging becomes too complex when messages are 'exclusive' (logic depends on processing order). I'm sure that with careful design, your approach would work very well for many scenarios, like workflow engines or billing data flows. BTW, what is your approach to distributing incoming messages between processing nodes?

Ayende Rahien commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 22:25:46 GMT

Rafal, The problem with pessimistic locking is that it doesn't scale very well. If I have 10 machines, and each machines can handle 8 threads, I have 80 process handling threads. Pessimistic locking take this thread out for a while, even in the case where we have no contention. Using this approach, I am able to avoid any locking scenarios. That is leaving aside the issue of this actually happening in the real world. If we take the amazon sample, it is pretty common for me to browse in several tabs at the same time, and order at the same time or nearly so.

Rafal commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 22:20:02 GMT

I was joking, but anyway, its complex, especially when you start considering some real world cases. What I was trying to say was that when you have millions of different sagas you get the parallelism from the fact that they are independent objects, not independent versions of the same object. And thus probability that two threads will be modifying the same object is low, so we can use pessimistic locking without taking too much risk. BTW, do you have to group by bureau name when merging? Is it possible that one bureau sends two scores?

Ayende Rahien commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 21:33:16 GMT

I _said_ it was notepad code.

Ayende Rahien commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 21:29:48 GMT

Rafal, Are you saying that this is complex or not? And I would have a saga per customer yes, but locking is a _very_ expensive operation. If I lock I am holding a thread captive. I don't have that many threads. And that is leaving aside the problem of _trying_ to lock in a distributed env.

configurator commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 20:53:55 GMT

Rafal commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 19:48:30 GMT

If this is dealing with complexity, I don't want to know how you deal with simplicity :) I've got one question: suppose this is real system and you're checking the credit of millions of users (I assume we're dealing with millions - maybe it's Amazon.com?). Do you really need to keep multiple versions of a saga? Usually you'll have sagas related to different customers, so if you kept a single version of each saga and locked it properly to prevent concurrent updates it wouldn't have a negative impact on overall system performance. Or would it?

Bill Pierce commented on Rhino Service Bus: Concurrency Violations are Business Logic

Wed, 21 Jan 2009 17:18:41 GMT

My recollection of another implementation from the NSB group is for the Saga State to be retrieved and updated transactionally. First simultaneous message updates the state, TryCompleteSaga returns, second simultaneous message updates the state, and fails because of a "stale state" (excuse the pun) exception, so the message is put back in the queue and processes successfully on the second try. This assumes some sort of timestamp/version on the state and something like NH, but removes the dependency on DHT and state merges. I have no implementation experience but I would presume the DHT and state merging would enable higher throughput than the transaction state.