Synclock in Begin request must be bad right?

Discussion in 'ASP .Net' started by Rory Becker, Jun 10, 2008.

  1. Rory Becker

    Rory Becker Guest

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

    This does work but I'm worried about performance
     
    Rory Becker, Jun 10, 2008
    #1
    1. Advertising

  2. Rory Becker

    Rory Becker Guest

    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


    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.

    --
    Rory
     
    Rory Becker, Jun 10, 2008
    #2
    1. Advertising

  3. Rory Becker

    Rory Becker Guest

    Ok move on nothing to see here.

    Just some shmuck accessing...

    -------------------------------------------------------------
    HttpContext.Current.Request.ApplicationPath
    -------------------------------------------------------------

    ....from Application_start when...

    -------------------------------------------------------------
    HttpRuntime.AppDomainAppVirtualPath
    -------------------------------------------------------------
    ....would have worked just as well
     
    Rory Becker, Jun 10, 2008
    #3
  4. 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:
    .

    ==================================================
    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: <>
    >From: Rory Becker <>
    >Subject: Re: Synclock in Begin request must be bad right?


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

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


    >
    >
     
    Steven Cheng [MSFT], Jun 11, 2008
    #4
  5. Rory Becker

    Rory Becker Guest

    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.


    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


    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.


    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

    --
    Ror
     
    Rory Becker, Jun 11, 2008
    #5
  6. 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:
    .

    ==================================================
    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: <>
    >From: Rory Becker <>
    >Subject: Re: Synclock in Begin request must be bad right?


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

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

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

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


    >
    >
     
    Steven Cheng [MSFT], Jun 11, 2008
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Birtle
    Replies:
    2
    Views:
    2,194
    John Saunders
    Oct 16, 2003
  2. NeoGeoSNK
    Replies:
    25
    Views:
    974
    NeoGeoSNK
    Nov 24, 2006
  3. Spam Catcher
    Replies:
    2
    Views:
    491
    Spam Catcher
    Mar 7, 2007
  4. david.karr
    Replies:
    4
    Views:
    1,587
    3rdshiftcoder
    Mar 27, 2007
  5. rantingrick
    Replies:
    44
    Views:
    1,306
    Peter Pearson
    Jul 13, 2010
Loading...

Share This Page