Comments on: No more workflow for nServiceBus – please welcome the Saga http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/ Enterprise Development Expert & SOA Specialist Sat, 11 Feb 2012 15:16:10 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: udidahan http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-37438 udidahan Fri, 10 Sep 2010 13:42:59 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-37438 Maninder, This comment format makes it a bit difficult to have a conversation, and others in the NServiceBus community would probably benefit from it as well. As such, I suggest we move this to the discussion group: http://tech.groups.yahoo.com/group/nservicebus Thanks. Maninder,

This comment format makes it a bit difficult to have a conversation, and others in the NServiceBus community would probably benefit from it as well. As such, I suggest we move this to the discussion group:

http://tech.groups.yahoo.com/group/nservicebus

Thanks.

]]> By: Maninder Batth http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-37432 Maninder Batth Wed, 08 Sep 2010 18:14:32 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-37432 Udi, Perhaps i was not able to put my question across in my last post. I am confused how can repeatable read isolation level lead to a correct behavior in a saga under the scenario where the same saga is loaded across multiple machines? To my understanding, repeatable reads will produce same results within a single transaction. But across machines, with different transactions how can the saga ensure correct behavior? One way to achieve this would be that saga subscribes to events across machines. Hence for example, if a particular saga is loaded in 2 different machines, then any events related to that saga would be multicast and consequently saga on different machines sync up their state. Another implementation could be via optimistic concurrency. Hence,i am interested in your approach to tackle such issues? Secondly, i think restricting saga to process steps that need to run sequential is bit restricting. Again if i understand saga correctly, it maintains process state in a long running transaction. If that definition is correct, then saga should be able to handle parallelism. Udi,
Perhaps i was not able to put my question across in my last post.
I am confused how can repeatable read isolation level lead to a correct behavior in a saga under the scenario where the same saga is loaded across multiple machines? To my understanding, repeatable reads will produce same results within a single transaction. But across machines, with different transactions how can the saga ensure correct behavior?
One way to achieve this would be that saga subscribes to events across machines. Hence for example, if a particular saga is loaded in 2 different machines, then any events related to that saga would be multicast and consequently saga on different machines sync up their state.
Another implementation could be via optimistic concurrency.
Hence,i am interested in your approach to tackle such issues?

Secondly, i think restricting saga to process steps that need to run sequential is bit restricting. Again if i understand saga correctly, it maintains process state in a long running transaction. If that definition is correct, then saga should be able to handle parallelism.

]]> By: udidahan http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-37429 udidahan Wed, 08 Sep 2010 11:56:55 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-37429 Maninder, The transactional isolation level for saga endpoints can be set to whatever level you like - repeatable read is usually safe enough; read committed enables higher parallelism but may lead to incorrect behavior. Sagas aren't meant to be used for everything - they're primarily for the parts of processes that can't be parallelized. Standard message handlers are for the parts which can run fully in parallel. Sagas and handlers integrate with each other by sending messages to each other. Maninder,

The transactional isolation level for saga endpoints can be set to whatever level you like – repeatable read is usually safe enough; read committed enables higher parallelism but may lead to incorrect behavior.

Sagas aren’t meant to be used for everything – they’re primarily for the parts of processes that can’t be parallelized. Standard message handlers are for the parts which can run fully in parallel. Sagas and handlers integrate with each other by sending messages to each other.

]]> By: Maninder Batth http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-37428 Maninder Batth Wed, 08 Sep 2010 00:37:01 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-37428 Udi, I was wondering what are the techniques to ensure that saga produces correct result when the same saga could be loaded in multiple machines or processes and accessed concurrently? So far, optimistic locking seems to be the easiest way out. As i live in the java world, i was wondering what are the various techniques used in nservicebus? Also Is there a way in nservicebus's saga implementation to describe what activities can proceed in parallel vs a serial fashion and the locking model for those activities? Udi,
I was wondering what are the techniques to ensure that saga produces correct result when the same saga could be loaded in multiple machines or processes and accessed concurrently? So far, optimistic locking seems to be the easiest way out. As i live in the java world, i was wondering what are the various techniques used in nservicebus?
Also Is there a way in nservicebus’s saga implementation to describe what activities can proceed in parallel vs a serial fashion and the locking model for those activities?

]]> By: Workflows, service buses, sagas… - Vagif Abilov's blog on .NET http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-36374 Workflows, service buses, sagas… - Vagif Abilov's blog on .NET Wed, 08 Jul 2009 17:27:53 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-36374 [...] the system to use Workflow Foundation. Udi Dahan (a man behind NServiceBus) refers in his blog to Saga concept – a model to handle long-running transaction that was first described in 1987 in the article by [...] [...] the system to use Workflow Foundation. Udi Dahan (a man behind NServiceBus) refers in his blog to Saga concept – a model to handle long-running transaction that was first described in 1987 in the article by [...]

]]> By: Durable Messaging Is Not Enough http://www.udidahan.com/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/comment-page-1/#comment-13808 Durable Messaging Is Not Enough Wed, 09 Jan 2008 23:17:37 +0000 http://udidahan.weblogs.us/2007/12/17/no-more-workflow-for-nservicebus-please-welcome-the-saga/#comment-13808 [...] in general terms how it ties back into durable messaging and transaction - in essence describing a saga. Let’s do this in story [...] [...] in general terms how it ties back into durable messaging and transaction – in essence describing a saga. Let’s do this in story [...]

]]>