Why I can not combind the SqlTracking & SqlPerstance Service in RC4?
Hi .
I have a sample app written in beta2.2, which simple do persistent and tracking. all my workflow.
when I upgrade to RC4, it wont works !
I go back to the foundatmental SDK samples. "SimpleTrackingSample" in RC4.
run it again, see the code is simple and fine, then I add some code to do
SqlPersistent stuff. but, it wont work !!!, It will always run intoWorkflowAbortedevent. but why ?
any one can help ?
here are my sample.
const string connectionString = "Initial Catalog=WorkflowTrackingStore;Data Source=.;Integrated Security=SSPI;";
const string connectionString2 = "Initial Catalog=WorkflowPersistenceStore;Data Source=.;Integrated Security=SSPI;";
static void Main()
{
try
{
using (WorkflowRuntime workflowRuntime = new WorkflowRuntime())
{
workflowRuntime.AddService(new SqlTrackingService(connectionString));
SqlWorkflowPersistenceService pService =
new SqlWorkflowPersistenceService(
connectionString2,
true,
TimeSpan.MaxValue,
new TimeSpan(0, 2, 0));
workflowRuntime.AddService(pService);
workflowRuntime.WorkflowCompleted += OnWorkflowCompleted;
workflowRuntime.WorkflowTerminated += OnWorkflowTerminated;
workflowRuntime.WorkflowAborted += OnWorkflowAborted;
WorkflowInstance workflowInstance =
workflowRuntime.CreateWorkflow(
typeof(SimpleTrackingWorkflow)
, null
, Guid.NewGuid()
);
Guid instanceId = workflowInstance.InstanceId;
workflowRuntime.StartRuntime();
workflowInstance.Start();
waitHandle.WaitOne();
workflowRuntime.StopRuntime();
GetInstanceTrackingEvents(instanceId);
GetActivityTrackingEvents(instanceId);
... skips
[1937 byte] By [
PoloLee] at [2007-12-22]
Attached a debugger and break on all managed exceptions. Make sure and turn off the just my code feature (Tools->Options->Debug). It will most likely be one of the issues suggested above. DTC being disabled is a common problem.
When using the SqlTrackingService and the SqlWorkflowPersistenceService you can avoid DTCs in many (but not all) cases by specifying the SharedConnectionWorkflowCommitWorkBatchService. This allows these services to share a single connection which eliminates the propegation to a DTC transaction and also reduces the number of sql connections that are opened. You'll see better performance as a result.
Thanks,
Joel West
MSFTE - SDE in WF runtime and hosting
This posting is provided "AS IS" with no warranties, and confers no rights
Yes, that is correct. However we highly recommend putting all database work that uses the same transaction in the same database (assuming that SqlTrackingService.IsTransaction is true, which is the default, it will share the same transaction as the persistence service when it writes to the db). The reason for this recommendation is to avoid DTCs.
There is a perf cost to DTCs which is nice to avoid but there is also the issue of maintaining consistency across multiple databases in regards to backup and restore. If you need the data in the two databases to be consistent (which is why a DTC would be used in the first place) then you also need to be sure that if you should lose your databases (mdf files) and need to restore from backup that the data will still be consistent. To do this you need to use log backups in conjunction with log marks. This rules out using a lot of Sql Server's built in backup and restore tools including their log shipping (which you can write a replacement yourself) and mirroring. See the Sql Server Books Online document for additional information (topic "Ensuring Recoverability of Related Databases" in 2005 and, I think, "Recovery of Related Databases" in 2000).
Sometimes you need the functionality that DTCs provide and when you really need them, they're great. Just good to be aware of the surrounding issues.
Thanks,
Joel West
MSFTE - SDE in WF runtime and hosting
This posting is provided "AS IS" with no warranties, and confers no rights
