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.