Serializing a request for an ASP page containing COM objects

Discussion in 'ASP General' started by Max, Aug 1, 2006.

  1. Max

    Max Guest

    Due to the behaviour of a particular COM object, I need to ensure that a
    request for a particular ASP page is finalized before another request for
    the page is processed. Does IIS have a way to ensure that subsequent
    requests will be queued until the current request is completed?

    If not, can IIS be configured to use seperate processes to satisfy requests
    for a nominated ASP page?

    Thanks in advance.

    Max
     
    Max, Aug 1, 2006
    #1
    1. Advertising

  2. Max

    Bobbo Guest

    Max wrote:

    > Due to the behaviour of a particular COM object, I need to ensure that a
    > request for a particular ASP page is finalized before another request for
    > the page is processed. Does IIS have a way to ensure that subsequent
    > requests will be queued until the current request is completed?
    >
    > If not, can IIS be configured to use seperate processes to satisfy requests
    > for a nominated ASP page?


    As far as I'm aware, you can only specify process isolation on a
    per-application basis. This procedure varies with the version of IIS
    you're using.

    Here's the procedure for version 6 (my version):
    http://www.microsoft.com/technet/pr...2ba-39fc-4332-bdb7-a0d9c76e4355.mspx?mfr=true
     
    Bobbo, Aug 1, 2006
    #2
    1. Advertising

  3. "Max" <> wrote in message
    news:44cf04dd$0$1509$...
    > Due to the behaviour of a particular COM object, I need to ensure that a
    > request for a particular ASP page is finalized before another request for
    > the page is processed. Does IIS have a way to ensure that subsequent
    > requests will be queued until the current request is completed?
    >
    > If not, can IIS be configured to use seperate processes to satisfy
    > requests for a nominated ASP page?
    >
    > Thanks in advance.


    Hi Max, as long as you don't have more web servers that serve the same
    website (ie url like www.yoursite.com) you can lock your page, through a
    Mutex object.
    A mutex, enables multiple processes on the same machine to synced single
    access to a single event.
     
    Egbert Nierop \(MVP for IIS\), Aug 1, 2006
    #3
  4. Max wrote:
    > Due to the behaviour of a particular COM object, I need to ensure
    > that a request for a particular ASP page is finalized before another
    > request for the page is processed. Does IIS have a way to ensure that
    > subsequent requests will be queued until the current request is
    > completed?
    > If not, can IIS be configured to use seperate processes to satisfy
    > requests for a nominated ASP page?
    >

    If the object is not free-threaded, storing it in Application may accomplish
    your goal. This is the reason we constantly advise against storing ADO
    objects (such as Connections) in Application: they are apartment-threaded so
    they can only service one thread at a time, in effect serializing all uses
    of the object.

    --
    Microsoft MVP - ASP/ASP.NET
    Please reply to the newsgroup. This email account is my spam trap so I
    don't check it very often. If you must reply off-line, then remove the
    "NO SPAM"
     
    Bob Barrows [MVP], Aug 1, 2006
    #4
  5. "Bob Barrows [MVP]" <> wrote in message
    news:...
    > Max wrote:
    > > Due to the behaviour of a particular COM object, I need to ensure
    > > that a request for a particular ASP page is finalized before another
    > > request for the page is processed. Does IIS have a way to ensure that
    > > subsequent requests will be queued until the current request is
    > > completed?
    > > If not, can IIS be configured to use seperate processes to satisfy
    > > requests for a nominated ASP page?
    > >

    > If the object is not free-threaded, storing it in Application may

    accomplish
    > your goal. This is the reason we constantly advise against storing ADO
    > objects (such as Connections) in Application: they are apartment-threaded

    so
    > they can only service one thread at a time, in effect serializing all uses
    > of the object.
    >


    It's a nice idea but the application object simply disallows
    apartment-threaded objects.


    > --
    > Microsoft MVP - ASP/ASP.NET
    > Please reply to the newsgroup. This email account is my spam trap so I
    > don't check it very often. If you must reply off-line, then remove the
    > "NO SPAM"
    >
    >
     
    Anthony Jones, Aug 1, 2006
    #5
  6. "Bobbo" <> wrote in message
    news:...
    >
    > Max wrote:
    >
    > > Due to the behaviour of a particular COM object, I need to ensure that a
    > > request for a particular ASP page is finalized before another request

    for
    > > the page is processed. Does IIS have a way to ensure that subsequent
    > > requests will be queued until the current request is completed?
    > >
    > > If not, can IIS be configured to use seperate processes to satisfy

    requests
    > > for a nominated ASP page?

    >
    > As far as I'm aware, you can only specify process isolation on a
    > per-application basis. This procedure varies with the version of IIS
    > you're using.
    >
    > Here's the procedure for version 6 (my version):
    >

    http://www.microsoft.com/technet/pr...2ba-39fc-4332-bdb7-a0d9c76e4355.mspx?mfr=true
    >


    On it's own it doesn't help serialise access to the page. It may be
    possible to tweak the application metadata to allow only one worker thread
    then only one request into the application can be processed at a time.

    One approach might be to enable debugging. That limits the app to a single
    thread but care needs to be taken that any configured debugger doesn't block
    operation (e.g. Dr Watson style debugging is ok but script debugger will
    just hang the process if there is an error).

    If there is only one CPU then setting AspProcessorThreadMax to 1 might also
    do it.

    Anthony.
     
    Anthony Jones, Aug 1, 2006
    #6
  7. Anthony Jones wrote:
    > "Bob Barrows [MVP]" <> wrote in message
    > news:...
    >> Max wrote:
    >>> Due to the behaviour of a particular COM object, I need to ensure
    >>> that a request for a particular ASP page is finalized before another
    >>> request for the page is processed. Does IIS have a way to ensure
    >>> that subsequent requests will be queued until the current request is
    >>> completed?
    >>> If not, can IIS be configured to use seperate processes to satisfy
    >>> requests for a nominated ASP page?
    >>>

    >> If the object is not free-threaded, storing it in Application may
    >> accomplish your goal. This is the reason we constantly advise
    >> against storing ADO objects (such as Connections) in Application:
    >> they are apartment-threaded so they can only service one thread at a
    >> time, in effect serializing all uses of the object.
    >>

    >
    > It's a nice idea but the application object simply disallows
    > apartment-threaded objects.
    >
    >

    I'm not sure I'm following your point. Could you expand on what you mean by
    "disallows"?

    --
    Microsoft MVP - ASP/ASP.NET
    Please reply to the newsgroup. This email account is my spam trap so I
    don't check it very often. If you must reply off-line, then remove the
    "NO SPAM"
     
    Bob Barrows [MVP], Aug 1, 2006
    #7
  8. Max wrote:
    > Due to the behaviour of a particular COM object, I need to ensure that a
    > request for a particular ASP page is finalized before another request for
    > the page is processed. Does IIS have a way to ensure that subsequent
    > requests will be queued until the current request is completed?
    > If not, can IIS be configured to use seperate processes to satisfy requests
    > for a nominated ASP page?
    > Max
    >

    Use the Application.Lock and Application.Unlock methods:
    ....
    Application.Lock
    ....
    'Critical section of code.
    ....
    Application.Unlock
    ....

    While there may be several copies of that page executing, the lock
    ensures that only one is be executing the critical section of code at
    any time. If a page finds the Application object locked, it will wait.

    It isn't necessary to store anything in the Application object. You're
    merely using the Application object's methods as a mutex to enforce
    serialized access to the critical section of code.

    Of course, serializing access will result in queuing and will slow
    response. So minimize the time and resources utilized in the critical
    section of code, enter it as late as possible and exit it as soon as
    possible.
     
    Michael D. Kersey, Aug 2, 2006
    #8
  9. Max

    Max Guest

    "Bob Barrows [MVP]" <> wrote in message
    news:%...
    > Anthony Jones wrote:
    >> "Bob Barrows [MVP]" <> wrote in message
    >> news:...
    >>> Max wrote:
    >>>> Due to the behaviour of a particular COM object, I need to ensure
    >>>> that a request for a particular ASP page is finalized before another
    >>>> request for the page is processed. Does IIS have a way to ensure
    >>>> that subsequent requests will be queued until the current request is
    >>>> completed?
    >>>> If not, can IIS be configured to use seperate processes to satisfy
    >>>> requests for a nominated ASP page?
    >>>>
    >>> If the object is not free-threaded, storing it in Application may
    >>> accomplish your goal. This is the reason we constantly advise
    >>> against storing ADO objects (such as Connections) in Application:
    >>> they are apartment-threaded so they can only service one thread at a
    >>> time, in effect serializing all uses of the object.
    >>>

    >>
    >> It's a nice idea but the application object simply disallows
    >> apartment-threaded objects.
    >>
    >>

    > I'm not sure I'm following your point. Could you expand on what you mean
    > by "disallows"?
    >
    > --
    > Microsoft MVP - ASP/ASP.NET
    > Please reply to the newsgroup. This email account is my spam trap so I
    > don't check it very often. If you must reply off-line, then remove the
    > "NO SPAM"
    >

    My thanks to Bobbo, Anthony, Egbert and Bob for their input.

    Unfortunately I may have some input on the setup of our clients web server
    but not on the machine it runs on. As I cannot guarantee a single
    processor, I cannot use your "set AspProcessorThreadMax to 1" suggestion.

    I am still looking at the suggestion to enable debugging although the
    possibility of the process just hanging on the customers site would not be
    acceptable.

    I am interested in Anthonys suggestion to "tweak the application metadata to
    allow only one worker thread" but am not sure which metadata values I would
    need to set to accomplish this.

    The COM object that I am using is marked as single threaded and doesn't
    appear to have any protection when IIS makes overlapping requests for the
    ASP page using it. We may be able to use a mutex but performance would be an
    issue.

    I have been looking into the use of a web garden (in IIS6) which appears to
    offer multiple processes on the same application. Do you think that using a
    web garden would be useful in this situation? Perhaps in combination with
    allowing only one worker thread as suggested by Anthony?

    Thanks in advance,

    Max
     
    Max, Aug 2, 2006
    #9
  10. "Bob Barrows [MVP]" <> wrote in message
    news:%...
    > Anthony Jones wrote:
    > > "Bob Barrows [MVP]" <> wrote in message
    > > news:...
    > >> Max wrote:
    > >>> Due to the behaviour of a particular COM object, I need to ensure
    > >>> that a request for a particular ASP page is finalized before another
    > >>> request for the page is processed. Does IIS have a way to ensure
    > >>> that subsequent requests will be queued until the current request is
    > >>> completed?
    > >>> If not, can IIS be configured to use seperate processes to satisfy
    > >>> requests for a nominated ASP page?
    > >>>
    > >> If the object is not free-threaded, storing it in Application may
    > >> accomplish your goal. This is the reason we constantly advise
    > >> against storing ADO objects (such as Connections) in Application:
    > >> they are apartment-threaded so they can only service one thread at a
    > >> time, in effect serializing all uses of the object.
    > >>

    > >
    > > It's a nice idea but the application object simply disallows
    > > apartment-threaded objects.
    > >
    > >

    > I'm not sure I'm following your point. Could you expand on what you mean

    by
    > "disallows"?
    >


    <%

    Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")

    Set Application("x") = o

    %>

    ASP just errors saying that assigning this sort of object into the
    application object is disallowed.
    You can only assign free-threaded objects into the application object.

    Assigning into the session is allowed but that will affiliate the session ID
    with a thread and all requests containing that session cookie will only ever
    be serviced be the affiliated thread (this doesn't help in the OP's case).
    Over time this will mean requests will queue up to be serviced even though
    worker threads are available because their affiliated thread is busy with
    another request. What's really annoying is that even if the object
    reference is only fleeting stored in the session object and then removed the
    thread will still remain affiliated.


    > --
    > Microsoft MVP - ASP/ASP.NET
    > Please reply to the newsgroup. This email account is my spam trap so I
    > don't check it very often. If you must reply off-line, then remove the
    > "NO SPAM"
    >
    >
     
    Anthony Jones, Aug 2, 2006
    #10
  11. "Michael D. Kersey" <> wrote in message
    news:%...
    > Max wrote:
    > > Due to the behaviour of a particular COM object, I need to ensure that a
    > > request for a particular ASP page is finalized before another request

    for
    > > the page is processed. Does IIS have a way to ensure that subsequent
    > > requests will be queued until the current request is completed?
    > > If not, can IIS be configured to use seperate processes to satisfy

    requests
    > > for a nominated ASP page?
    > > Max
    > >

    > Use the Application.Lock and Application.Unlock methods:
    > ...
    > Application.Lock
    > ...
    > 'Critical section of code.
    > ...
    > Application.Unlock
    > ...
    >
    > While there may be several copies of that page executing, the lock
    > ensures that only one is be executing the critical section of code at
    > any time. If a page finds the Application object locked, it will wait.
    >
    > It isn't necessary to store anything in the Application object. You're
    > merely using the Application object's methods as a mutex to enforce
    > serialized access to the critical section of code.
    >
    > Of course, serializing access will result in queuing and will slow
    > response. So minimize the time and resources utilized in the critical
    > section of code, enter it as late as possible and exit it as soon as
    > possible.


    It should be pointed out that this will affect all uses of application
    locks. If the application is to contain other pages (not connected with the
    problem in question) use application locks these pages will be affected
    also.

    IOW the Application object itself can be used as a single global mutex.
    Personally I prefer Egbert's solution.
     
    Anthony Jones, Aug 2, 2006
    #11
  12. Anthony Jones wrote:
    >> I'm not sure I'm following your point. Could you expand on what you
    >> mean by "disallows"?
    >>

    >
    > <%
    >
    > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")
    >
    > Set Application("x") = o
    >
    > %>
    >
    > ASP just errors saying that assigning this sort of object into the
    > application object is disallowed.


    Interesting. I've never tried that so I never encountered that error. I have
    just confirmed what you are saying, however.


    > You can only assign free-threaded objects into the application object.


    ADO objects aren't free-threaded (unless marked as such in the registry) ...
    why does IIS allow people to store ADO recordsets and connections in
    application?


    --
    Microsoft MVP - ASP/ASP.NET
    Please reply to the newsgroup. This email account is my spam trap so I
    don't check it very often. If you must reply off-line, then remove the
    "NO SPAM"
     
    Bob Barrows [MVP], Aug 2, 2006
    #12
  13. "Bob Barrows [MVP]" <> wrote in message
    news:...
    > Anthony Jones wrote:
    > >> I'm not sure I'm following your point. Could you expand on what you
    > >> mean by "disallows"?
    > >>

    > >
    > > <%
    > >
    > > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")
    > >
    > > Set Application("x") = o
    > >
    > > %>
    > >
    > > ASP just errors saying that assigning this sort of object into the
    > > application object is disallowed.

    >
    > Interesting. I've never tried that so I never encountered that error. I

    have
    > just confirmed what you are saying, however.
    >
    >
    > > You can only assign free-threaded objects into the application object.

    >
    > ADO objects aren't free-threaded (unless marked as such in the registry)

    ....
    > why does IIS allow people to store ADO recordsets and connections in
    > application?
    >


    ADO uses a free threaded marshaller in this case. Hence the object
    reference the application stores is in fact a free threaded proxy for the
    ADO object rather than a reference to the object itself. Of course as soon
    as anything tries to call a method on the proxy the calling thread will
    block while the call is marshalled across to the thread that originally
    created the object. If that thread is busy with another request (or some
    other marshalled call from yet another thread) then the call blocks.
    Therefore as you say it is not a good idea to store ADO objects in the
    application object.



    >
    > --
    > Microsoft MVP - ASP/ASP.NET
    > Please reply to the newsgroup. This email account is my spam trap so I
    > don't check it very often. If you must reply off-line, then remove the
    > "NO SPAM"
    >
    >
     
    Anthony Jones, Aug 2, 2006
    #13
  14. Anthony Jones wrote:
    >> ADO objects aren't free-threaded (unless marked as such in the
    >> registry) ... why does IIS allow people to store ADO recordsets and
    >> connections in application?
    >>

    >
    > ADO uses a free threaded marshaller in this case. Hence the object
    > reference the application stores is in fact a free threaded proxy for
    > the ADO object rather than a reference to the object itself. Of
    > course as soon as anything tries to call a method on the proxy the
    > calling thread will block while the call is marshalled across to the
    > thread that originally created the object. If that thread is busy
    > with another request (or some other marshalled call from yet another
    > thread) then the call blocks. Therefore as you say it is not a good
    > idea to store ADO objects in the application object.
    >
    >

    OK, that makes sense ... thanks. We never stop learning.

    --
    Microsoft MVP -- ASP/ASP.NET
    Please reply to the newsgroup. The email account listed in my From
    header is my spam trap, so I don't check it very often. You will get a
    quicker response by posting to the newsgroup.
     
    Bob Barrows [MVP], Aug 2, 2006
    #14
  15. Anthony Jones wrote:
    > <%
    >
    > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")
    >
    > Set Application("x") = o
    >
    > %>


    You failed to lock the Application object in your example, which should
    read:
    > <%
    > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")

    Application.Lock
    > Set Application("x") = o

    Application.UnLock
    > %>


    Assuming, of course, that the object is free-threaded.
     
    Michael D. Kersey, Aug 2, 2006
    #15
  16. Anthony Jones wrote:
    <snipped>
    >
    > It should be pointed out that this will affect all uses of application
    > locks. If the application is to contain other pages (not connected with the
    > problem in question) use application locks these pages will be affected
    > also. IOW the Application object itself can be used as a single global mutex.


    As clearly documented by Microsoft.

    > Personally I prefer Egbert's solution.


    Certainly Egbert's is the most general solution. But no debugged code
    was provided.

    In it's favor, my suggestion is quick, easy to apply, clearly works as
    designed by Microsoft and the tested code is provided above.

    My suggestion will work until that mutex method is written and debugged.
    Or even forever, if need be. [Yes, billions and billions of ASP pages
    running until the _end_ _of_ _time_, bwaahaahaaahaaaa!]

    My suggestion is certainly better than the two you suggested earlier:
    1-enable debugging or
    2-setting AspProcessorThreadMax to 1
    which were both very amusing. Thanks for the laugh.

    All in all, I think you're embarrassed that you missed this most obvious
    suggestion, one designed by Microsoft. Reason I say that is that, in the
    example you gave where you stored an object into the Application object,
    you neglected to lock and unlock the Application object, a common newbie
    error. Just a guess; I could be wrong, of course.
     
    Michael D. Kersey, Aug 2, 2006
    #16
  17. Michael D. Kersey wrote:
    > Anthony Jones wrote:
    > <snipped>
    >>
    >> It should be pointed out that this will affect all uses of
    >> application locks. If the application is to contain other pages (not
    >> connected with the problem in question) use application locks these
    >> pages will be affected also. IOW the Application object itself can
    >> be used as a single global mutex.

    >
    > As clearly documented by Microsoft.
    >
    >> Personally I prefer Egbert's solution.

    >
    > Certainly Egbert's is the most general solution. But no debugged code
    > was provided.
    >
    > In it's favor, my suggestion is quick, easy to apply, clearly works as
    > designed by Microsoft and the tested code is provided above.
    >
    > My suggestion will work until that mutex method is written and
    > debugged. Or even forever, if need be. [Yes, billions and billions of
    > ASP pages running until the _end_ _of_ _time_, bwaahaahaaahaaaa!]
    >
    > My suggestion is certainly better than the two you suggested earlier:
    > 1-enable debugging or
    > 2-setting AspProcessorThreadMax to 1
    > which were both very amusing. Thanks for the laugh.
    >
    > All in all, I think you're embarrassed that you missed this most
    > obvious suggestion, one designed by Microsoft. Reason I say that is
    > that, in the example you gave where you stored an object into the
    > Application object, you neglected to lock and unlock the Application
    > object, a common newbie error. Just a guess; I could be wrong, of
    > course.


    Is there some history between you two here? This is verging on being
    insulting (perhaps even crossing the line), and Im not sure the insult
    was called for. From what I could see, Anthony was expressing a
    preference for a technique, not disparaging yours, which he did
    acknowledge would accomplish the OP's purpose.

    I am sure that Anthony is aware of the need to lock Application, and
    simply left it out of his example because he was sure I was aware of the
    need to do that as well.


    --
    Microsoft MVP -- ASP/ASP.NET
    Please reply to the newsgroup. The email account listed in my From
    header is my spam trap, so I don't check it very often. You will get a
    quicker response by posting to the newsgroup.
     
    Bob Barrows [MVP], Aug 2, 2006
    #17
  18. "Michael D. Kersey" <> wrote in message
    news:...
    > Anthony Jones wrote:
    > > <%
    > >
    > > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")
    > >
    > > Set Application("x") = o
    > >
    > > %>

    >
    > You failed to lock the Application object in your example, which should
    > read:


    What happens if you don't call Lock, Unlock?

    > > <%
    > > Dim o: Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")

    > Application.Lock
    > > Set Application("x") = o

    > Application.UnLock
    > > %>

    >
    > Assuming, of course, that the object is free-threaded.
    >
     
    Anthony Jones, Aug 2, 2006
    #18
  19. Anthony Jones wrote:

    > IOW the Application object itself can be used as a single global
    > mutex. Personally I prefer Egbert's solution.


    How does one create a mutex in vbscript without using
    application.lock...unlock?
    I was not aware that thread could be created in scripting ...
    --
    Microsoft MVP -- ASP/ASP.NET
    Please reply to the newsgroup. The email account listed in my From
    header is my spam trap, so I don't check it very often. You will get a
    quicker response by posting to the newsgroup.
     
    Bob Barrows [MVP], Aug 2, 2006
    #19
  20. "Michael D. Kersey" <> wrote in message
    news:%...
    > Anthony Jones wrote:
    > <snipped>
    > >
    > > It should be pointed out that this will affect all uses of application
    > > locks. If the application is to contain other pages (not connected with

    the
    > > problem in question) use application locks these pages will be affected
    > > also. IOW the Application object itself can be used as a single global

    mutex.
    >
    > As clearly documented by Microsoft.
    >
    > > Personally I prefer Egbert's solution.

    >
    > Certainly Egbert's is the most general solution. But no debugged code
    > was provided.
    >
    > In it's favor, my suggestion is quick, easy to apply, clearly works as
    > designed by Microsoft and the tested code is provided above.
    >
    > My suggestion will work until that mutex method is written and debugged.
    > Or even forever, if need be. [Yes, billions and billions of ASP pages
    > running until the _end_ _of_ _time_, bwaahaahaaahaaaa!]
    >
    > My suggestion is certainly better than the two you suggested earlier:
    > 1-enable debugging or
    > 2-setting AspProcessorThreadMax to 1
    > which were both very amusing. Thanks for the laugh.
    >


    I agree. I was just enjoying thinking up mad ways to achieve this like I
    said Egbert's is best if although better yet would be to design out the
    requirement altogether.

    > All in all, I think you're embarrassed that you missed this most obvious
    > suggestion, one designed by Microsoft. Reason I say that is that, in the
    > example you gave where you stored an object into the Application object,
    > you neglected to lock and unlock the Application object, a common newbie
    > error. Just a guess; I could be wrong, of course.


    It is of course possible that you are wrong. I've posted a question in
    another branch perhaps you can enlighten this 'newbie' rather than just
    being obnoxious. (Is that spelt right?)
     
    Anthony Jones, Aug 2, 2006
    #20
    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. Christopher V. Kimball

    Serializing generic objects

    Christopher V. Kimball, Dec 11, 2004, in forum: Java
    Replies:
    0
    Views:
    342
    Christopher V. Kimball
    Dec 11, 2004
  2. sangha
    Replies:
    4
    Views:
    611
    Ashish Pagey
    Mar 8, 2006
  3. Replies:
    3
    Views:
    493
    Thomas Hawtin
    Apr 6, 2006
  4. john smith
    Replies:
    0
    Views:
    370
    john smith
    Aug 9, 2003
  5. Steve

    Objects containing objects

    Steve, Jan 13, 2008, in forum: Perl Misc
    Replies:
    2
    Views:
    80
    Paul Lalli
    Jan 13, 2008
Loading...

Share This Page