2

I've a long running task in my asp.net web application and hence I run that task in a new thread and constantly poll to check the status of the thread (by using a ticker control which ticks every 5 seconds and postbacks to the server and checks the status of the thread). I used the Session State to share the variables between the thread and the page. But I learned that it is a bad practice to access the session from a background thread. What is the best method to share variables between a thread and the asp.net page which created that thread?

NLV
  • 21,141
  • 40
  • 118
  • 183
  • `But I learned that it is a bad practice to access the session from a background thread` What is (supposedly) "bad" about it? It is just accessing a pointer in memory. – Cos Callis May 27 '11 at 13:09
  • Here you go http://stackoverflow.com/questions/5096789/asynchronous-threads-and-session – NLV May 27 '11 at 13:10
  • @Cos Callis: the obvious reason I can think of it being bad is because if its a long running task the session might be terminated before its finished for a variety of reasons. Also if the user is browsing the site in multiple tabs it is possible that values can be overwritten (eg if the user is trying to do the same thing for two different parameters sets then its very easy to write code that overwrites them, etc.). – Chris May 27 '11 at 13:22
  • @Chris (& @NLV...) But if the service (long running task) is using session as a communication layer (`I used the Session State to share the variables between the thread and the page`) between service and **page** then an abandoned session should not affect the service and vice versa... as for whether multiple pages could cause collisions, that would be a scenario driven issue that may or may not manifest. I am still not prepared to agree that _in this case_ using session is "bad". (Although a case could be made that something else is better...) – Cos Callis May 27 '11 at 13:38
  • 1
    @Cos Callis: I admit to not having given a great depth of thought to it but I would say having a shared resource that could be overwritten by other things (eg other page calls) seems like a bad idea. The problem is it is a communication between page and service that anybody can screw up by deleting, writing other stuff to, etc. That having been said nobody has stepped forward with a better way of doing it yet so it could be that other techniques are not practical leaving this as the best solution and therefore not bad practice almost by definition. :) – Chris May 27 '11 at 13:54

2 Answers2

1

It is not a direct answer to your question, rather a suggestion to use a separate WCF service for the long running jobs. Your web server gets really busy working on a long task, which I assume use lots of CPU.

Anticipated problems

  • The overall performance of web server will drop
  • You will not be able to scale such solution

Alternatively, consider putting the long running logic into a WCF service. You can start and check the job status by issuing simple AJAX query with the ID of the job. Each job can be started in a separate thread and the result/status persisted into a queriable storage.

oleksii
  • 35,458
  • 16
  • 93
  • 163
  • good alternative, I think as a good design practice this should be implemented, keep the backend process separate from the application, but then it is not easy to move all the logic to a separate service. – shabby Jul 12 '12 at 04:05
1

I don't inherently see an issue with using Session - it's basically a thread-safe dictionary. You probably need to ensure that your background thread locks SyncRoot; the Page class does this automatically.

There are, of course, other options as well - static variables (but then you get into AppDomain issues), or out-of-band mechanisms (which is what Session is) like a DB or messaging service. Unless you have some other need for those technologies, though, Session is probably the simplest.

Couple of caveats I can think of:

  • If the Session expires, what happens when writing to it from the background thread? Exception? Keeps it alive?
  • How do you detect that the background thread has exited abnormally? Store the thread in Session?
  • What happens to Session if there's an unhandled exception on the background thread?
Mark Brackett
  • 84,552
  • 17
  • 108
  • 152
  • I've designed a ThreadStatus class which holds all the information about the thread like progress percentage, whether the thread has complete running, whether it has completed the task successfully without errors, if not what is the exception etc. And I don't think the session will expire when I'm doing a constant polling every 3 or 5 seconds. – NLV May 28 '11 at 06:45
  • @NLV - no, but if your session is in-proc, an app restart will kill it. You'll also need to ensure that your ThreadStatus is thread-safe; the Session will only synchronize read/writes to it - not to your class. – Mark Brackett May 29 '11 at 20:42