Intermittent loss of session variables

[Steve Remer]

OK, I think I understand session state pretty well. I've done
additional research on Google over the last few days to fill in any
holes.

To begin with, I'm using StateServer and not InProc for SessionState
mode in my web.config. In fact, that's the only mode Verio shared
hosting supports. That should eliminate about 70% of the reasons
Session objects get destroyed from what I can tell.


Here's the situation:

This is a class registration system. When the user is ready to
register, they of course click a button and the event handler picks up
their entered credit card info along with user data accumulated in
Session variables. About 30% to 40% of the time, the operation fails
at the SQL server level as the registration is written to a table
(MSSQL INSERT). An INSERT trigger is fired because the userID in the
about to be written registration does not correspond to any user in
the users table. A referential integrity error is thrown and
percolates up until it reaches my app-level error checking in
global.asax

Notice (below) that in addition to the stack trace, I capture the
SessionID as well as the User Name and email (at bottom of listing). I
capture those last two directly from the same Session variables
directly from global.asax.

The listing of the error is below, but based on it I think I can
determine three things:

1. The ASP.NET session is still active, otherwise there would be no
SessionID.

2. The Session variables, at least User Name and Email but probably
all, are empty.

3. The referential integrity error occurs because the Session variable
from which the UserID is retrieved is also empty. MSSQL sees that
there is no UserID and rightly rejects the INSERT.

To repeat, this process work just fine 60% of the time. We haven't
been able to see any odd things about specific users or specific
classes.

HERE IS ERROR LISTING. It's always the same and is emailed to me.
________________________________________________________________
The following error occured on the CWI system at 10:53:45 AM

Exception of type System.Web.HttpUnhandledException was thrown.

at System.Web.UI.Page.HandleError(Exception e)
at System.Web.UI.Page.ProcessRequestMain()
at System.Web.UI.Page.ProcessRequest()
at System.Web.UI.Page.ProcessRequest(HttpContext context)
at System.Web.CallHandlerExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
Boolean& completedSynchronously)

Inner Exception:

The record can't be added or changed. Referential integrity rules
require a related record in table 'tblUsers'.

at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior
cmdBehavior, RunBehavior runBehavior, Boolean returnStream)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at CWINewsReg.CWI.CustomersDB.AddRegOrWait(Int32 classid, Int32
custid, Int32 spaces, Boolean wait, String regtype, String ccname,
String ccnum, String cctype, String ccexpdate, String note) in
C:\Inetpub\wwwroot\CWIRegDev\CustomersDB.vb:line 378
at CWINewsReg.Register.btnRegister_Click(Object sender, EventArgs
e) in C:\Inetpub\wwwroot\CWIRegDev\Register.aspx.vb:line 187
at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String
eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
sourceControl, String eventArgument)
at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection
postData)
at System.Web.UI.Page.ProcessRequestMain()

SessionID: r4exgxmyv1i5b145gqb4q045

User name:
User email:

 

[Bryan Donaldson]

The listing of the error is below, but based on it I think I can
determine three things:

1. The ASP.NET session is still active, otherwise there would be no
SessionID.

This is the basic error in your thinking, I believe. There is ALWAYS a
session id. When the old one times out, and the user comes back in, a new
one is assigned. It MIGHT even have the same value as the last one.. but
it's a different session.

If you're having these errors frequently (and I'd say 30-40% is frequently)
then you need to find another place to store your users' information. You
might look at some of the examples on the web where this kind of information
is stored in a DB table or in an XML document that resides on the client.
Search for "shopping cart" examples.

 

[Steve Remer]

This is the basic error in your thinking, I believe. There is ALWAYS a
session id. When the old one times out, and the user comes back in, a new
one is assigned. It MIGHT even have the same value as the last one.. but
it's a different session.

If you're having these errors frequently (and I'd say 30-40% is frequently)
then you need to find another place to store your users' information. You
might look at some of the examples on the web where this kind of information
is stored in a DB table or in an XML document that resides on the client.
Search for "shopping cart" examples.

I appreciate that insight. I had no idea that a SessionID could be
held over like that. Based on the questions I've asked and the
research I've done, I think I'll take your advice and punt on the
Session variables, much as I hate to. I'm inclined to go the DB route.
Are cookies still considered unreliable because of users setting their
preferences to avoid cookies? After all, even ASP.NET session state
depends on cookies unless you tell it otherwise, as you probably know.