How to respect a transaction flowed via TransactedReceiveScope when using an AsyncCodeActivity

Question

Hello!

When I ececute an AsyncCodeActivity within a TransactedReceiveScope I notice that the transaction is not scoping the behaviour done by the AsyncCodeActivity, i.e. this behaviour commits despite the transaction flowed in will abort.

Therefore: How to respect a transaction flowed in via TransactedReceiveScope when using an AsyncCodeActivity?

Best regards,

Henrik Dahl

Answer 1

Hi Henrik,
I had expected it would be automatic, but there might be a gotcha being encountered here somewhere.
-What async operation are you doing? Are you marshalling the operation to another thread explicitly, or is it implicit in the API? Is it a .Net API? Which one?
-Generally what kind of behavior is the AsyncCodeActivity doing, is it using transaction aware APIs, which are the ones you are seeing with unexpected non-commital behavior?
-Is this a distributed transaction scenario?
Tim

Answer 2

Hello Tim!

I just want to add an EntityObject to an EntityCollection using the Entity .NET Framework inside the scope of a distributed transaction where hosting is done using Windows Server AppFabric.

I would like to give another idea: Can't you just give or refer to a small sample how it should be programmed correctly when doing something using the Entity .NET Framework inside an AsyncCodeActity in a situation, where the hosting is done using Windows Server AppFabric and a distributed transaction is in power by the means of a TransactedReceive activity, please?

Best regards,

Henrik Dahl

Answer 3

Again - as far as I know it should just work, so I'm still trying to work out whether I'm just wrong, or there's something particular about what you're doing. I'm also still learning about Entity Framework.

In particular I want to understand where is the asyncness coming from in your async activities? As far as I read so far EF 4.1 (not sure which version you are on) doesn't support the asynchronous programming model by default.

Are you using some asyc methods specific to/generated by the entity framework? Or are you spawning your own thread or task for doing things asynchronously? Or marshalling actions using some kind of dispatcher or synchronization context?
Tim

Answer 4

Ambient Transactions are thread bound.  That is why it isn't working.  You could use a CodeActivity and it would work fine then.

---

Sr. Program Manager, Windows Azure Platform Team(WF) http://blogs.msdn.com/rjacobs http://www.twitter.com/ronljacobs

Answer 5

Hello Ron!

This is exactly how I understood it and how I therefore did it. I have however watched your videos, where you invited Leon Welicki and talked about being a good runtime citizen. I think we can say that it's pretty clear that you should not hijack a workflow thread for your own processing, that I/O matters should be delegated to other threads using an AsyncCodeActivity. As far as I remember it was even emphasized that using a database evidently falls to this heavy category.

I think we could also say that if we exclude the small dummy samples, database work will obviously be done inside a transaction and typically they'll be received via a TransactedReceiveScope.

It does not seem very appropriate that you cannot be a good runtime citizen if you need to engage in a transaction for which ever purpose as you probably need transactions for all non-trivial enterprise purposes.

By the way I think it could be very valuable if you would be crafting more of such nice and informative videos.

Best regards,

Henrik Dahl

Answer 6

I know this is a scenario that other people will be interested in. I've tried to expand information available the scenario here:

http://blogs.msdn.com/b/tilovell/archive/2012/03/13/wf4-transactions-implementation-of-transactions-in-wf4-and-implications.aspx

I believe you should be able to flow the transaction to your thread where you are doing async work.
Tim

Answer 7

Hello Tim!

Yes, this is an excellent description of the problem including relevant background information.

Do you also have a solution for the problem?

Best regards,

Henrik Dahl