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
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