Just to clarify some on this:

I can store simple strings, ints, and DataSets if I do so from the main
page processing thread. The problem only occurs when I attempt to set a
DataSet or anything else in the session from the background thread (yet can
still modify the struct created by the foreground thread).





Kevin_Hoffman@c... on 02/07/2003 09:26:15 AM

Please respond to "ASPX_Professional" <aspx_professional@p...>

To:   "ASPX_Professional" <aspx_professional@p...>
cc:

Subject:  [aspx_professional] Problems with SQL State management and
      multi-threading...

Has anyone else encountered this issue or found a workaround?

Here's my scenario:
   Creating a multi-threaded search page. When the search page first is
hit, a background thread is created to execute the search. The foreground
(page) thread then proceeds to poll a semaphore (flag) stored in the
session (SQLState) to see if the search has completed. If it has not
completed within 40 seconds, it re-directs the user to a PleaseWait.aspx
page. This page then continues to periodically check the status of the
semaphore for the background search thread.

When the background thread has retrieved its results (this can sometimes
take several minutes), it modifies the semaphore in the session to indicate
that it has completed its task, and then attempts to store the results
(DataSet) in the session so they can be retrieved by the original search
page on re-direct back.

The problem is this: The background thread is able to modify the contents
of the semaphore (a struct containing a few ints and strings) just fine, as
the code can detect that it has completed its task, which is only possible
when the semaphore indicates "Completed". However, the attempt to store the
results (DataSet) in session fails. There is no error, but the new item
does not appear in session. As a "sanity test", I also store "Hello World"
in the session  just to see if that works, and it does not. No item in
session, and absolutely no exception is thrown (seen all this through
tracing/debugging). I have also tried attaching the DataSet to the struct
that is already in session, and this too results in a null w/out any thrown
exception. Additionally, I verified that the sessionid in the foreground
and background thread both match 100%, so that is not an issue.

Here's the rub: when I switch from SQLState to InProc for state
maintenance, it works like a champ. The entire thing runs so wonderfully I
should demand a raise. The only problem is: our app is designed for a farm
and InProc session state is useless in that case. I can't use cookies
because cookies have a 4,000 character limit and some of my result sets
have thousands of /rows/ of data.

So, here's my question: Does anybody know why a backgruond thread can
modify a struct in session without any problem, but cannot store a new
string or a DataSet (alone or part of a [Serializable()] struct), and
doesn't throw an exception? If you do know why, what is the workaround? And
why would SQLState not handle it and InProc handle it just fine? I know I
can't store un-serializable objects in SQL session state, but this is a
DataSet, which I know is explicitly serializable, and a simple string,
which I know is perfectly legal to store in the session.

Is this a bug, a feature, an annoyance, and is there a workaround?

Any help is greatly appreciated.

Sincerely,
     Kevin Hoffman
     Problem - Design - Solution: Professional ASP.NET Website Programming,
Professional ASP.NET e-Commerce Website Programming.