Reply to thread

Message: [QUOTE="George Ter-Saakov, post: 3435822"] I am not sure about implications of passing Session to another thread but in general I would not do that. Unless you want to troubleshoot your application for the rest of your life :) --------------------------------------------------- I would create something more robust. 1. Table in DB tblJobs(JobId, Owner, Status, TimeIn, TimeOut, MessageIn, MessageOut) Status = (Pending, Processing, Completed) Owner is who kciked off the job. List specific UserId 2. To kick of the job you insert record into tblJobs with MessageIn having XML serialized object needed to do the job (like bunch of parameters). Also you would need to increase "ActiveJobs" counter in the sesssion. 3. Some External Thread/External Process/MSMQ (your choice) pooling Jobs to-do from the table and working on it. After it's done it populates TimeOut and MessageOut with XML serialized object of the result of the job. 4. Your aspx page is checking for ActiveJobs counter if it's not 0 then checks result of the job(s) submitted by that Owner. Updates Session if job is completed..... -------------------------------------------------------------------- PS: In order to avoid multithreading/multiprocessing problems you must be careful. Always do optimistic locking when updating tblJobs Meaning that if you have more than one process/thread that pools tblJobs for new jobs then folow following steps (actually always do that) 1. Get a pending job "SELECT ... FROM tblJobs Where status = Pending" 2. Set status to processing "UPDATE tblJobs SET status=Processing WHERE JobId=1 AND status = Pending" 3. Check that 1 (not 0) records were updated. SqlCommand.ExecuteNonQuery returns that. 4. If returned value was 1 then proceed to execute job. If it's 0 then do not execute job cause it was grabbed by other pooling thread between step 1 and 2. George. George. [/QUOTE]

Verification