1

I have an .NET 4.0 ASP.NET MVC application, which also hosts a Workflow Foundation 4.0. From within this workflow, some custom workflow activity will execute code to do some database updates using Linq to SQL. The code consists of calling a method, which in turn call some other methods etc... I also have a business layer which has a data access factory, providing access to all of my data access objects containing the methods for database operations.

Now suppose I my WF activity calls method A , which in turn calls method B in another class, which calls method C end D in yet another class. In each of these methods I want to retrieve the same instance of my data accesss factory, so that all database operations are excuted on the same database transaction. How would I design the singleton pattern for my data access factory? Note that methods A, B, C and D also can be called from Asp.Net MVC controllers.

When methods A, B,C and D are called from asp.net mvc controllers, its easy, I can use the HttpContext to store my data access factory singleton, so that within one http request I also get the same instance of my data access factory.

But when these methods are called from the Workflow activity, there is no HttpContext of course. I tried thread static variable, but in web applications you're not sure, method A, B, C en D will be called on the same thread. I also tried CallContext, but I experienced, I'm not always retrieving the same instance, so apparently CallContext is not the solution either.

Basically, the problem can be summarized as 'getting the same instance of an object in a background process running in an asp.net application' (it doesn't matter whether this background task is kicked of by the WF activity or another way of background tasks e.g. using Task<T>)

rekna
  • 5,313
  • 7
  • 45
  • 54

3 Answers3

2

Not really related to your question but doing background tasks in a asp.net application is awful, I speak from experience.

The Dangers of Implementing Recurring Background Tasks In ASP.NET

Micah Armantrout
  • 6,781
  • 4
  • 40
  • 66
  • So the proper solution would be (if I understand the article correctly) a WCF service hosted as a Windows Service? Can I use this same windows service to host the workflow host as well ? – rekna Apr 05 '12 at 23:00
  • http://msdn.microsoft.com/en-us/library/ms733069.aspx - looks like it is possible. I have never done it – Micah Armantrout Apr 06 '12 at 13:42
1

Since your object would need to cross process and memory space, I would create a WCF service that hosts your factory as a singleton instance. That way, the MVC application can call into it and the WF application can call into it.

Josh
  • 10,352
  • 12
  • 58
  • 109
  • A singleton in the WCF service would not work, since each call would receive the same instance of the dao factory. And a dao factory is associated with a transaction, so different wcf calls would intefere each other transactions. So in a WCF service, I have to use CallContext? – rekna Apr 05 '12 at 22:56
0

I know this is old, but I figured this would also help.

HttpContext.Current is null when checked on interceptor

It when running the workflow service (.xamlx), you want to utilize the OperationContext with your entity object.

Community
  • 1
  • 1
user959729
  • 1,127
  • 2
  • 12
  • 19
  • Also, see http://stackoverflow.com/questions/1895732/where-to-store-data-for-current-wcf-call-is-threadstatic-safe This provides the .Items dictionary object for the Workflow WCF to store the entity context per WCF instance – user959729 Aug 14 '12 at 14:55