Ten Reasons why WF is not a Toy

New and Notable 115

Sam Gentile — Tue, 17 Oct 2006 17:18:29 GMT

There is so much I want to say about important topics like Rocky's well-written, thought provoking Semantic

re: Ten Reasons why WF is not a Toy

buj — Tue, 17 Oct 2006 19:11:50 GMT

Try turning on FIPS and using WF...

Windows Workflow Foundation Resources

while(availableTime>0) { — Tue, 17 Oct 2006 19:55:40 GMT

Since I´ve been working with Windows Workflow Foundation (Project BHAL), I´ve gathered quite a list of...

re: Ten Reasons why WF is not a Toy

Jon Flanders — Tue, 17 Oct 2006 20:50:15 GMT

Paul - I feel compelled to come to Harry's defense (not of his use of the word toy necessarily ;-)) - but I was the one who gave him his information. Please check out my most recent entry for clarification. http://www.masteringbiztalk.com/blogs/jon/PermaLink,guid,5cc60ee3-38ce-4fcd-94d7-a8ca9b3b8d5d.aspx

re: Ten Reasons why WF is not a Toy

kcmarshall — Wed, 18 Oct 2006 20:31:29 GMT

Um -

"...once it releases in November 2007."

Are you saying that WF (and .NET 3.0) will be officially released in 11/07? Did I miss that elsewhere? Or do you mean something else by "it"?

Kevin

re: Ten Reasons why WF is not a Toy

pandrew — Wed, 18 Oct 2006 21:59:13 GMT

Hi Kevin,

Windows Workflow Foundation will release with the .NET Framework 3.0. That's scheduled to release at the same time as Windows Vista goes RTM. See: http://www.microsoft.com/presspass/press/2006/Oct06/10-13VistaReleasePR.mspx

Regards,

Paul

re: Ten Reasons why WF is not a Toy

Keith Woods — Thu, 19 Oct 2006 06:48:52 GMT

Thanks for clarifying what exactly gets loaded, just wondering is there any particular reason you load the workflows that are not started when you start the runtime? Just noticed we may need to rethink our batch creation strategy. Currently we create and unload about 4000 workflows and intent to start them at a later time. They appear to get loaded when the runtime start as they are not locked and not blocked (this takes a while).

If there is a good reason for loading them we wont mod the code/stored proc that loads unstarted runtimes, otherwise we’ll probably start them when we create them and put them into an intermittent state waiting for a later kick-off.

Perhaps this is not the forum to discuss this but we’ve been trying to identify the best practices regarding how to use the SQL persistence service.

re: Ten Reasons why WF is not a Toy

pandrew — Thu, 19 Oct 2006 07:13:32 GMT

Hi Keith,

The persistence service does not load the workflow instances that are not started. It only loades instances that are ready to run.

I don't know why you think you're seeing that. You must have some other problem. I'd suggest you take it up on the MSDN Forums. http://www.windowsworkflow.net/forums.

Also did you review the SDK documentation? http://windowssdk.msdn.microsoft.com/en-us/library/ms734764(VS.80).aspx

Regards,

Paul

Heated Debate on Workflow ;-)

Mike Taulty's Blog — Thu, 19 Oct 2006 13:06:42 GMT

There's been a bit of a heated debate on Workflow Foundation going on which Paul Andrew captured and...

RetrieveNonBlockingInstanceStateIds does load non-started workflows

piers7 — Thu, 19 Oct 2006 17:08:42 GMT

Sorry Paul, but I can't let you off the hook on this one yet, because what you're saying just doesn't tally with the tests we've done.

In the code in front of me I create and persist a non-started workflow. It goes into the database with a status of '4'. In the 'RetrieveNonBlockingInstanceStateIds' I can clearly see that statuses of 4 *are* loaded by this proc (which is called by the SqlWorkflowPersistenceService at runtime startup)

SELECT uidInstanceID FROM [dbo].[InstanceState] WITH (TABLOCK,UPDLOCK,HOLDLOCK)

WHERE blocked=0 AND status<>1 AND status<>3 AND status<>2 -- not blocked and not completed and not terminated and not suspended

...and sure enough when I start the runtime I see the 'Workflows in Memory' performance counter rise by the number of persited, non-started workflows I have in the database. I'm not sure how I can mis-interpret this.

The only thing I wonder about is whether you've rev'd the stored procs after releasing the RC5 (.Net3 RC1) build, and you and I are looking at different code.

re: Ten Reasons why WF is not a Toy

pandrew — Thu, 19 Oct 2006 19:37:21 GMT

Hi Piers,

I'm working with Doug Orange at Microsoft Australia on this. Let's continue to discuss your debuging on that thread.

Regards,

Paul

El servicio de persistencia de Windows Workflow Foundation

O bruxo mobile — Tue, 28 Nov 2006 15:14:25 GMT

Hace ya bastante tiempo que llevo jugando con WF, puesto que lo necesitaba por exigencias de trabajo,