Session lock-up issue when requesting one webform from another.

[Thomas Nielsen [AM Production A/S]]

Hi,

I have one web form (WebForm1.aspx) from which i would like to display the
output of another web form, WebForm2.aspx, in a controlled environment. I do
this by using HttpWebRequest to request WebForm2 from the WebForm1
code-behind, and this works flawlessly.

I would also like to be able to share the Session objects between the two
webforms. I'm trying to do this by passing the ASP.NET_SessionId cookie on
WebForm1 to WebForm2. This should trick IIS into believing both requests are
within the same session.
However, it seems that IIS locks up WebForm2 (it doesn't respond) when the
session ID for both forms is identical. It should be noted that both web
forms are placed in the same web application, and that i suspect this is the
reason for the lock-up. I've tried placing WebForm2 in a different web
application, and then there are no lock-up problems - But then they are
ofcourse not sharing sessions even though their session IDs are identical.

Any hints would be appreciated.

Cheers,

/Thomas

 

[[MSFT]]

Hi Thomas,

Can you explain more about why you need to dispaly content from another web
form? In such a situation, I would like suggest a asp.net web control
instead. For example, you can easily convert the second web form to a web
control and used it in the first web form. Can this resolve the problem?

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Thomas Nielsen [AM Production A/S]]

Luke,

I realize the solution is "exotic", but the reason is that my first WebForm
is part of a proprietary system that i do not fully control. For example -
There are currently problems using Viewstate within this system, and this
would affect whichever User Controls i would (dynamically) load on to the
page.

If I were able to completely isolated "execute" WebForms from within the
system, I would be able to avoid taking host system-specific issues into
consideration. I would also be able to insert content from any external
webservers into my page, which would also be an advantage for me.

Cheers,

/Thomas

 

[[MSFT]]

Hi Thomas,

Actually, we cannot isolate the "execute" in that way. All request will be
handle in same process (ASP.NET).

To get around this problem, I think you may consider adding the session
variant to QueryString or Form of the request, so that the target web form
can get the value.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Cosmin Marin]

Hi,

If you really need access to session in both forms, you could try
Server.Execute() from within WebForm1 to render WebForm2. We might loose
some stuff like url authorization, if you are using it.
The problem you are experiencing comes from the fact that the session is
locked during the lifetime of a request that asks for access to the
session. The lock type depends on the type of access that you want (r/w or
r/o), but as soon as you ask fo r/w access, you have the requests on the
same session serialized.

Cosmin

 

[Thomas Nielsen [AM Production A/S]]

Luke,

Not quite sure i follow you on this one. Why is it a problem (to the Session
object) that both requests are handled from within the same process?.

/Thomas

 

[Thomas Nielsen [AM Production A/S]]

Cosmin,

OK - That explains my problems. There's no way you know of that will allow
me to force unlocking the session?

I was considering Server.Execute too, but then everything is inherited from
the page which i execute from (for instance, Viewstate may be switched off
from WebForm1). I would rather be able to "sandbox" execute/render my forms
into this one form.

Cheers,

/Thomas

 

[[MSFT]]

Thank you Cosmin's answer. I agee with him too. And I don't think there is
way to force unlocking the session. You may need to find other ways to
share the data between the pages.

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)