CSLA and Workflow

CSLA and Workflow

Old forum URL: forums.lhotka.net/forums/t/7312.aspx


pondosinat posted on Tuesday, July 21, 2009

I want to say that after following the workflow guidance laid out in ch. 3 of the CSLA 3.0 e-book, I couldn't be happier with CSLA's workflow integration and Rocky's recommendations on using it with CSLA. I did come across a "gotcha" that I'm struggling with: when calling a WF from within the DataPortal_Update of my BOs, I have been getting a lot of SQL timeouts, caused by deadlocking of certain tables.

It turns out that because the CSLA update method wraps both the BO update and WF activity in the same transaction, it's very easy to have any Select statements in your WF workflow get blocked and, subsequently, timeout. I'm assuming that the reason is the WF project and my ASP.NET project are opening two different connections to the db, so SQL thinks I'm two different users and decides to block me. It took quite a bit of troubleshooting (and adding a lot of (NOLOCK) hints, which did no good) to arrive at this conclusion.

The solution is to wrap any update calls in your BO with a manual transaction, and THEN call your workflow. Unfortunately, I lose the ability to roll back my entire transaction. How to work around this? I suppose I could get around this by passing my connection object to the workflow?

RockfordLhotka replied on Tuesday, July 21, 2009

I don't think you can do this.

WF is designed to isolate the workflow from the caller, and to that end I think they prevent you from passing object references into or out of the workflow.

If you pass an object into a workflow through the arguments dictionary, WF will serialize the object and the workflow actually gets a clone of the original object. ADO.NET connection objects aren't serializable, so the serialization would fail.

A couple of my colleagues at Magenic mentioned, just a few days ago, that they thought .NET 3.5 SP1 with SQL Server 2008 had addressed the TransactionScope issue, so a connection reclaimed through connection pooling wouldn't trigger the DTC. I haven't had time to try and confirm this yet, but it might help?

Otherwise I don't know of any answer that would avoid the DTC and still get you complete transactional protection over the entire operation.

If you can do two transactions - one for your object, another for the workflow, that's easy, because you can create your own TransactionScope objects instead of using the CSLA Transactional attribute.

pondosinat replied on Tuesday, July 21, 2009

Very interesting - I am in fact using .NET 3.5 SP1 and SQL Server 2008 SP1 but the DTC behavior you mentioned is not there as far as I can tell.

Using two transactions will have to be good enough then. That's not a big deal for me, though it's good to know that doing single transaction may be a possibility in the future.

Copyright (c) Marimer LLC