Re: Can anybody explain this? (InProc Session locking broken)
- From: "George Ter-Saakov" <gt-nsp@xxxxxxxxxxx>
- Date: Tue, 10 Jan 2006 14:45:49 -0500
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
"Nick" <Nick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0C11541E-11AF-40EF-82E4-BB2CCE92540F@xxxxxxxxxxxxxxxx
> 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/en-us/dnaspp/html/ASPNETProvMod_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
>
.
- Follow-Ups:
- Prev by Date: Re: Designing a 3 teir architecture at our development environment.
- Next by Date: Re: Timer control
- Previous by thread: What's the server control equivalent of <input type="image"> ?
- Next by thread: Re: Can anybody explain this? (InProc Session locking broken)
- Index(es):
Relevant Pages
|
