Can I reconnect to a session that has timed out or been abandoned

[Big Daddy]

We have a problem where the session is getting abandoned for no
apparent reason. It's not timing out. We save some important data in
the Session object. The user will click on something, causing a
postback, and there will be nothing in the Session object. The session
is getting restarted with the same session ID. Since we haven't been
able to stop this from happening, we would like to just reconnect the
user to their old session data. We've been storing it in process, but
will probably have to switch to out of process (e.g. SQL Server), so
that it can persist. So this is what would happen: If a postback
occurs and there is no data in the Session cache, we'd just try to
reconnect to the old Session cache using the same Session ID. Is this
possible?

thanks in advance,
John

 

[Guest]

We have a problem where the session is getting abandoned for no
apparent reason. It's not timing out. We save some important data in
the Session object. The user will click on something, causing a
postback, and there will be nothing in the Session object. The session
is getting restarted with the same session ID. Since we haven't been
able to stop this from happening, we would like to just reconnect the
user to their old session data. We've been storing it in process, but
will probably have to switch to out of process (e.g. SQL Server), so
that it can persist. So this is what would happen: If a postback
occurs and there is no data in the Session cache, we'd just try to
reconnect to the old Session cache using the same Session ID. Is this
possible?

First of all, check if it could be the reason of your problem
http://support.microsoft.com/kb/316148/

If it's not the case, I would suggest to use the database to save the
session data

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

We have a problem where the session is getting abandoned for no
apparent reason. It's not timing out. We save some important data in
the Session object. The user will click on something, causing a
postback, and there will be nothing in the Session object. The session
is getting restarted with the same session ID. Since we haven't been
able to stop this from happening, we would like to just reconnect the
user to their old session data. We've been storing it in process, but
will probably have to switch to out of process (e.g. SQL Server), so
that it can persist. So this is what would happen: If a postback
occurs and there is no data in the Session cache, we'd just try to
reconnect to the old Session cache using the same Session ID. Is this
possible?

thanks in advance,
John

A new session never gets the same session id as the previous one. If you
have the same session id, you have the same Session object. This
suggests that there actually is something in your code that removes the
session variables.

 

[Guest]

A new session never gets the same session id as the previous one. If you
have the same session id, you have the same Session object. This
suggests that there actually is something in your code that removes the
session variables.

Göran:

Q: Why does the SessionID remain the same after the Session times out
or abandoned?
A: Even though the session state expires after the indicated timeout
period, the session ID lasts as long as the browser session. What this
implies is that the same session ID can represent multiple sessions
over time where the instance of the browser remain the same.

http://www.eggheadcafe.com/articles/20021016.asp

 

[Mark Rae]

A new session never gets the same session id as the previous one.

This is simply untrue: http://support.microsoft.com/?kbid=899918

Specifically: "When you abandon a session, the session ID cookie is not
removed from the browser of the user. Therefore, as soon as the session has
been abandoned, any new requests to the same application will use the same
session ID but will have a new session state instance."

 

[Big Daddy]

First of all, check if it could be the reason of your problemhttp://support.microsoft.com/kb/316148/

If it's not the case, I would suggest to use the database to save the
session data

I don't think the problem that the session is getting restarted is
because of antivirus software, as suggested by the article. We have
already looked into that.

As for your suggestion of using the database, do you mean coming up
with our own home-designed solution that is like a session cache, or
do you mean using the session where the mode is SQLServer and ASP.NET
automatically saves the session cache in the database? If you mean the
latter, that would be fine with me...I just don't know how to
reconnect to the session data after the session has been restarted.

thanks again,
John

 

[Guest]

As for your suggestion of using the database, do you mean coming up
with our own home-designed solution that is like a session cache
Yes.

If you mean the
latter, that would be fine with me...I just don't know how to
reconnect to the session data after the session has been restarted.

I don't think this would be possible.

In any case, I think it is better to find why the session is getting
abandoned.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Göran:

Q: Why does the SessionID remain the same after the Session times out
or abandoned?
A: Even though the session state expires after the indicated timeout
period, the session ID lasts as long as the browser session. What this
implies is that the same session ID can represent multiple sessions
over time where the instance of the browser remain the same.

http://www.eggheadcafe.com/articles/20021016.asp

I see. I thought that would clearly be a security risk, but perhaps it
isn't.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

This is simply untrue: http://support.microsoft.com/?kbid=899918

Specifically: "When you abandon a session, the session ID cookie is not
removed from the browser of the user. Therefore, as soon as the session has
been abandoned, any new requests to the same application will use the same
session ID but will have a new session state instance."

I see. I thought that would clearly be a security risk, but perhaps it
isn't.

 

[Mark Rae]

I see. I thought that would clearly be a security risk, but perhaps it
isn't.

I couldn't agree more!!! There are some, er, features of the Framework which
are unfathomable (to me, at least...) and this is one of them...