Synclock in Begin request must be bad right?

  • Thread starter Thread starter Rory Becker
  • Start date Start date
R

Rory Becker

I have had code in my Application_Start which is intended to run once at
the start of my application's life.

It loads connection information and similar from a known location.

However I recently migrated my app using
-------------------------------------------------------------
%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "Default Web Site/YourApp"
-------------------------------------------------------------

At which point my app's startup code was denied access to the request object.

I found a workaround which was to place the following code in the beginrequest

-------------------------------------------------------------
Private Shared InitializeLock As New Object
Private Shared InitializedAlready As Boolean
Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
' Fires at the beginning of each request
SyncLock InitializeLock
If Not InitializedAlready Then

' My Initialise code goes here.

InitializedAlready = True
End If
End SyncLock
End Sub
 
Damn "Send" hotkeys. Sorry about that. I sent the previous message before
I was done writing it.
This does work but I'm worried about performance
Click to expand...

Specifically it occurs to be that I now have a bottleneck in my application
which only one request can pass through at any one time.

This does not seem good for a web site.

Please tell me there is a better way.


Thanks in advance for any help.
 
Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Start event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.

2. You can not get "HttpContext.Current.Request.ApplicationPath" property
work in Application_Start event

As for the 1st problem, I wonder what is the exact object you're trying to
access, is it an COM object or something else, would you provide some code
snippet or further description? Such "Access denied" error is commonly
caused by security permission issues, therefore, is that certain object
access permission sensitive? If so, have you used "impersonate" in your
ASP.NET web application. If you have used impersonate, the security account
under which the ASP.NET code executes are different between
Application_Start and the "Begin_Request"(or any other page level event).
This is because Application_Start executes at application level(there may
not exists any request context), it runs under ASP.NET worker process
account. Why "Begin_Request" is under the certain ASP.NET client request's
context, if you have used imperonate, it is running under the impersonate
account.


for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.Current.Request.ApplicationPath" this is a property coupled
with the current request's "HttpContext". For each client request to
ASP.NET application, the runtime will attach an HttpContext object with the
request(during the server-side processing lifecycle). However,
Applicaiton_start event is not a Request based event, it is just a global
application level event, there is no HttpContext associated with it,
therefore, if you try accessing any Httpcontext coupled property in it,
that will not be available.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
Date: Tue, 10 Jun 2008 11:30:57 +0000 (UTC)
Message-ID: <[email protected]>
From: Rory Becker <[email protected]>
Subject: Re: Synclock in Begin request must be bad right?
Click to expand...
 
Hello Steven Cheng [MSFT],
Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Start event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.
Click to expand...

My appologies if I gave the wrong impression here I am in fact able to access
the file in question, however I was having difficulty locating it as I needed
to locate the applications root directory and base it's location on that.
given that problem 2 is now solved, problem 1 ceases to exist.
2. You can not get "HttpContext.Current.Request.ApplicationPath"
property work in Application_Start event
Click to expand...

This was indeed the case.

for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.Current.Request.ApplicationPath" this is a property
coupled with the current request's "HttpContext". For each client
request to ASP.NET application, the runtime will attach an HttpContext
object with the request(during the server-side processing lifecycle).
However, Applicaiton_start event is not a Request based event, it is
just a global application level event, there is no HttpContext
associated with it, therefore, if you try accessing any Httpcontext
coupled property in it, that will not be available.
Click to expand...

However it did used to fire at a point in time when there was an httprequest
available. It is only since the migration that this event has shifted.

This however has led to my discovery of 'HttpRuntime.AppDomainAppVirtualPath'
which needs no such request to determine the information needed.


Thanks for your help anyway though
 
Thanks for your quick reply Rory,

I'm glad that you've found the solution. Yes, For ASP.NET web application,
in Application level event, it is better to avoid using those object which
is specific to HttpContext/Request. And the AppDomain properties you found
is not specific to any request context, but keep available based on the
given ASP.NET application(a certain .net AppDomain).

If you have any further questions, also welcome to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.--------------------
Date: Wed, 11 Jun 2008 07:23:52 +0000 (UTC)
Message-ID: <[email protected]>
From: Rory Becker <[email protected]>
Subject: Re: Synclock in Begin request must be bad right?
Click to expand...
Hello Steven Cheng [MSFT],
Hi Rory,

From your previous messages, you currently encounter the following two
problems, correct?

1.the code in your ASP.NET's Application_Start event which access a
certain object fails(with Access denied) after you switch to a new IIS
directory.
Click to expand...

My appologies if I gave the wrong impression here I am in fact able to access
the file in question, however I was having difficulty locating it as I needed
to locate the applications root directory and base it's location on that.
given that problem 2 is now solved, problem 1 ceases to exist.
2. You can not get "HttpContext.Current.Request.ApplicationPath"
property work in Application_Start event
Click to expand...

This was indeed the case.

for the 2nd problem, it is actuall the same with the 1st one,
"HttpContext.Current.Request.ApplicationPath" this is a property
coupled with the current request's "HttpContext". For each client
request to ASP.NET application, the runtime will attach an HttpContext
object with the request(during the server-side processing lifecycle).
However, Applicaiton_start event is not a Request based event, it is
just a global application level event, there is no HttpContext
associated with it, therefore, if you try accessing any Httpcontext
coupled property in it, that will not be available.
Click to expand...

However it did used to fire at a point in time when there was an httprequest
available. It is only since the migration that this event has shifted.

This however has led to my discovery of 'HttpRuntime.AppDomainAppVirtualPath'
which needs no such request to determine the information needed.


Thanks for your help anyway though
Click to expand...
 
Back
Top