asp.net session issue: variable drops after redirect

Just "used session again" as usual... but faced strange situation. .net 3.5

1. Inserted object into session variable.
2. Just in the next line - retrieved it successfully.
3. Redirected, retrieving - variable is default value, but object constructor wasn't called.

I will not describe how I spend few hours on debugging any operation that could reset the variable... because after those hours I'm just changed StateServer mode to InProc... and IT CAME TO LIFE )

Why? I used to see an exception if I'm trying to insert something non-serializable etc into stateserver - but i'm inserted and retrieved... Also in trace I saw an objects of same type in session, but with another ids. And finally - I'm using old, tested code (in case of redirection and session store or retrieving) BUT with new object type.

What's 开发者_如何学Chappening?)

EDITED:

Checked in firewall traffic on state-server port - asp doesn't send there anything during page request processing. That's why I can retrieve variable next line. But why he writes default object into state-server later?

What is the environment of your dev machine? Your your app pool process model section, how many worker process are you using?

If you are using inProc session state but your app pool process model uses more than 1 worker process you'll have this kind of issue.

Keep in mind that your app pool settings on your dev machine will most likely be different from your production machine. So changing between session state inproc and session state service has a huge implication.

A Response.Redirect can cause this behaviour; once the redirect is called a thread abort exception is thrown which can prevent the session variable from being set.

This issue can be overcome with the overload

Response.Redirect("~/default.aspx", false);

This call does not abort the thread and thus the session variable will be successfully set.

In the bottom class in serialized object hierarchy was founded class that wasn't marked as Serializable. Seems that asp couldn't throw such exception if non-serializable object is nested into subclasses. So stupid (