Can anybody explain this? (InProc Session locking broken)

G

Guest

We have recently discovered that on our production environment certain aspx
files, two to be certain, are displaying a behaviour we understand ought not
to be possible under the (ASP).Net Framework. The read/write lock on the
session object set by one request is being relinquished to a second request
BEFORE the first request has ended.

You can imagine the myriad of ugly situations that can arise from
simultaneous requests concurrently accessing the Session, in our case
including orphan transactions on SQL-Server, which by their (table) locks
have an inmense impact on subsequent requests.

We haven't been able to reproduce this on a development environment.

We coded our application based on the "paradigm" as supplied by MS
documentation here:
http://msdn.microsoft.com/library/e...Prt4.asp?frame=true#aspnetprovmod_prt4_topic2
(Ctrl-F for the word "lock")

So how are we so certain that the lock is being released to early? well he
have an extremely rich proprietry tracing and logging mechanism that allows
us to see in good detail what happened in a request thread when an error
occurs, from early on in request events all the way through the request
handler to late request events.

In these requests what we see is that the first request starts to get
handled and makes good progress for some time, then suddenly along comes this
other request into the same session where it sees that another process is
already active (by means of flags that the first request put up). The second
request tries its best to recover from the situation but that can become
quite complex... Anyways the second request finishes normally and then in the
HTTP log we can we see that the first request finally finishes quite some
time later.

How can be??!! Why isn't the the session object locked, or why is it being
released?

There are perhaps some hints at where the explanation might lie: in the
first request we know that it is potentially long running, so we:

1 jack up the Server.ScriptTimeout
2 lower the thread priority

We've been on many tangents on this one, including suspiccions that perhaps
POST's or ASMX WebMethod post's don't adhere to the above paradigm. But we've
been able to exlude those.

Oh yes, and I might mention we do NOT steer the session locking at all
ourselves, by means of page directives for read-only pages.

Anyone else's two-cents-worth will be much appreciated!

Nick and Robin, Reeleezee.com
 
G

George Ter-Saakov

Never had a problem with that.
Are you talking about .NET 1.1?
or 2.0? If 2.0 then everything can happen.

PS: What kind of logging/tracing are you using synchronous or asynchronous?
If you write to IIS log then it does not guarantee the order in which events
are reported. Look at the date/time stamp there. Not at the order in which
they are reported.

George
 
G

Guest

inGeorge, we're on .NET 1.1. We don't write to the IIS log, we write
synchronously to our own logs, one log file per request, with timestamps per
log line.

Just out of curiosity: does your reply constittute the "guaranteed reply
with 24 hours" that our MSDN subscription "entitles" us to?
Just asking, because nobody else seems interested in our post and we might
have to consider escalating this to an incident.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top