Jon Flanders posted a comment on my post yesterday about the changes in the new release of my MsmqActivities sample regarding the new subscription persistence functionality. I was going to respond on another comment, but I think this might be important enough to warrant its own post. Here's Jon comment: I am still concerned about your approach (essentially another persistence service to take care of). Especially in light of: a) How will this work in a mulit-host instance environment b) How will it stay consistent with the state of the workflow itself (what if your service gets out of sync with the current state of the workflow). Which is why I would prefer some system that used the metadata of the activity instance itself - I would lean toward SqlPersistenceService.GetAllWorkflows - which would allow you to get the activity metadata without having to load it into memory. OTOH - this is only on the OOB persistence service. Let me just start by mentioning that I actually share Jon's concern about this approach [1]. It is another persistence service to take care of and that brings up a number of issues and potentiall problems with it. Regarding point (a) Jon brings above, the answer is: it won't work well, for very obvious reasons. The primary one is actually related to how MSMQ itself works, and that's a significant limitation right there. If you have multiple hosts trying to listen to the same queue, then things won't really work very well. And, because of this, using this in a "load-balancing" scenario with multiple servers hosting the same workflows really wouldn't work at all as expected. Regarding point (b), yes, that's actually my biggest fear. Hopefully, it is not something that would happen too often (at least that's what I think from my tests, I could be wrong) but it is definitely a possibility. I'm going to be frank about this and say that right from the start I didn't want to have to implement something like this; it just feels wrong. I looked for other options but I just didn't see anything obvious that would work and at least workaround the underlying issue. My MsmqActivities have been a wonderful tool for me to understand a lot of concepts of WF. It's obvious that in many ways they are "toys", but precisely because of the requirements they impose they make, IMHO, a good sample to understand a lot of the implications of writing a full-fledged custom event activity that doesn't use the built-in services (i.e. HandleExternalEvent). Jon proposes a good idea, and that's trying to avoid having to do the external persistance of subscriptions in the first place and instead trying to rely on getting the necessary information to recreate the subscriptions from the workflow instances stored by the workflow persistence service. I'll explore this option further, but I do have my reservations if that information will be enough to get all information needed to recreate the subscriptions (including recognizing in which scenarios an activity is found
Read More...