So I've flattened my forehead trying to get the configuration section for WF set the way I wanted. The trick is to learn what the actual named parameters each service is expecting and then adding those as attributes to the <Services><add> element.
I'm sure others have already forged a trail here but I couldn't find any significant information about using the application config file to drive WF runtime configuration settings. The MSDN documentation give some hints but unfortunately there isn't nearly as much detail in the documentation for Workflow Foundation as there is for Windows Communication Foundation.
The best place I've found to see what named parameters are available to a service is to Reflector the workflow runtime assembly (System.Workflow.Runtime.dll ) which is located in the reference assemblies folder "\Program Files\Reference Assemblies\Microsoft\Framework\v3.0". I was looking for the settings I could configure for the SqlWorkflowPersistenceService so I drilled down to the constructor that accepted a NameValueCollection. Then I could see in the disassembly what settings would be read (screenshot below) in that constructor.
Using the names as indicated in the constructor I was able to add attributes to the element configuring the SqlWorkflowPersistenceService. The key one I was trying to figure out how to add was the OwnershipTimeoutSeconds which tells the service how to behave when locking instances in a common persistence database.
The configuration that I'm starting with is below. Eventually I'll be changing to a different palette of services but this meets the needs for now.
<configSections>
<section name="WorkflowRuntime"
type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection,
System.Workflow.Runtime, Version=3.0.00000.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</configSections>
<WorkflowRuntime Name="WorkflowMultiHost">
<CommonParameters>
<add name="ConnectionString"
value="Initial Catalog=WorkflowStore;Data Source=(local);Integrated Security=SSPI;" />
<add name="EnableRetries"
value="True" />
</CommonParameters>
<Services>
<add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService,
System.Workflow.Runtime,
Version=3.0.00000.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
<add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowCommitWorkBatchService,
System.Workflow.Runtime,
Version=3.0.00000.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
<add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService,
System.Workflow.Runtime,
Version=3.0.00000.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35"
UnloadOnIdle="True"
LoadIntervalSeconds="5"
OwnershipTimeoutSeconds="90" />
<add type="System.Workflow.Runtime.Tracking.SqlTrackingService,
System.Workflow.Runtime,
Version=3.0.00000.0,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
</Services>
</WorkflowRuntime>
Notice that I'm using the SharedConnectionWorkflowCommitWorkBatchService which allows the storage of persistence and tracking data to the same database. This allows non-DTC transactions which of course will perform better. I'll know more as I begin load testing and I'll be doing a post on what I find. Some folks at MS did a great writeup on various WF performance issues here.
Go with the flow...