Asp and Application.lock

  • Thread starter Thread starter Jennifer.Berube
  • Start date Start date
J

Jennifer.Berube

What is it exactly that makes application.lock such a bad thing? I
just need a better explanation or link to a resource desribing it's
downfall.
 
Access to the Application object is serialized to prevent the corruption
which could occur if more than one user writes to it at the same time.

The requests to modify application variables are queued up,
and they are given access in the order they were received.

That reduces performance somewhat, but prevents data corruption.

You should try to avoid letting users change application variables.




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
 
Access to the Application object is serialized to prevent the corruption
which could occur if more than one user writes to it at the same time.

The requests to modify application variables are queued up,
and they are given access in the order they were received.

That reduces performance somewhat, but prevents data corruption.

You should try to avoid letting users change application variables.

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/





- Show quoted text -

Well see....we had a huge bottleneck where the server rose up to 94%
usage and it was due to an application.lock command in a global.asa
file. It is for a visitor counter...
 
re:
It is for a visitor counter...

One of the flimsiest reasons to use Application.Lock.

I'd prefer to write to a text file which, even though it's also serialized,
creates far less contention than going through Application.Lock/Unlock.

There's a fairly decent sample you could adapt here :
http://www.asp101.com/samples/counter_aspx.asp

And there's another sample here :
http://www.codeproject.com/aspnet/EasyHit.asp

Adapt either one. Either that, or use a commercial counter.
Use *anything*, except code that uses Application.Lock/Unlock.

;-)




Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
===================================
Access to the Application object is serialized to prevent the corruption
which could occur if more than one user writes to it at the same time.

The requests to modify application variables are queued up,
and they are given access in the order they were received.

That reduces performance somewhat, but prevents data corruption.

You should try to avoid letting users change application variables.

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/

Well see....we had a huge bottleneck where the server rose up to 94%
usage and it was due to an application.lock command in a global.asa
file. It is for a visitor counter...
 
re:


One of the flimsiest reasons to use Application.Lock.

I'd prefer to write to a text file which, even though it's also serialized,
creates far less contention than going through Application.Lock/Unlock.

There's a fairly decent sample you could adapt here :http://www.asp101.com/samples/counter_aspx.asp

And there's another sample here :http://www.codeproject.com/aspnet/EasyHit.asp

Adapt either one. Either that, or use a commercial counter.
Use *anything*, except code that uses Application.Lock/Unlock.

;-)

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/







Well see....we had a huge bottleneck where the server rose up to 94%
usage and it was due to an application.lock command in a global.asa
file. It is for a visitor counter...- Hide quoted text -

- Show quoted text -

I agree...I'm the administrator but because I used to be a developer I
have become quite useful to the company because I can point out errors
in the coding. I just needed a solid answer to application.lock. I
was always taught it was a "no no" and to never do so I never really
looked into it further. Thanks!
 
Back
Top