The Code is the Design

For accessing controls in a different thread from which they were created, set (static variable) TextBox.CheckForIllegalCrossThreadCalls = false; http://msdn.microsoft.com/en-us/library/system.windows.forms.control.checkforillegalcrossthreadcalls.aspx Without this, you will get the error “Cross-thread operation not valid: Control accessed from a thread other than the thread it was created on” However, this is not a good idea for production code. http://discuss.joelonsoftware.com/default.asp?dotnet.12.460561.4 Please be warned

"For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details." I guess that rules out sharing session between WIP and IOF, unless they can have the same virtual dirs (maybe on different servers in WST) ... ... we don't specify app name in the session state tag. It gets picked up automatically.

Some design considerations I would mention are 1. Storing a datatable or dataset anywhere is always a bad idea. These classes maintain history and a ton of additional data Best practice is to create a class for a unit of data and store a list of objects of that class If the query is a simple one or the data is large, querying the DB again is preferable to serializing/storing/deserializing in session/viewstate/cache. 2. showModalDialog has an option to pass arguments – even a collection – from the javascript itself. http://msdn.microsoft.com/en-us/library/ms536759(VS.85).aspx No need to ever store or come to the backend This can be used instead of querying the DB again 3. Viewstate is an even more dangerous place to store heavy objects than session The network is burdened with MBs of traffic and both the browser and server are burdened with creating and storing the object Viewstate is specifically for small page-specific data (like global variables required across postbacks) The only pl