STA object in Session and Thread Affiliation

Discussion in 'ASP General' started by Anthony Jones, Feb 6, 2006.

  1. Here's a question that I've not been able to get a definitive answer to.

    Creating an STA object (such as a typical VB6 object) and assigning to the
    ASP Session store is a bad thing.

    It's a bad thing because it forces IIS to affiliate the Session with the
    Thread on which the STA object is created.

    This means all subsequent requests for that session can only be handled by
    that worker thread and can therefore result it in poor performance as
    requests queue up to access the thread they are affiliated with.

    My question(s) is/are this:

    Is this affilation now set in stone for the life time of the session?

    Does removing the STA object from the session remove the affiliation or is
    IIS/ASP just not that clever?

    Thanks,

    Anthony.
    Anthony Jones, Feb 6, 2006
    #1
    1. Advertising

  2. "Anthony Jones" <> wrote in message
    news:...
    > Here's a question that I've not been able to get a definitive answer to.
    >
    > Creating an STA object (such as a typical VB6 object) and assigning to the
    > ASP Session store is a bad thing.
    >
    > It's a bad thing because it forces IIS to affiliate the Session with the
    > Thread on which the STA object is created.
    >
    > This means all subsequent requests for that session can only be handled by
    > that worker thread and can therefore result it in poor performance as
    > requests queue up to access the thread they are affiliated with.
    >
    > My question(s) is/are this:
    >
    > Is this affilation now set in stone for the life time of the session?


    sure

    > Does removing the STA object from the session remove the affiliation or is
    > IIS/ASP just not that clever?


    Sure.

    ISP Session uses a workaround. But your VB class, needs to be persistable
    (this is just a property). And persistance, needs to be implemented, so
    within the VB6 class, you need to write the properties to a propertybag.
    In the session, they will be written to a byte array and vice versa when
    red.
    Persistable objects like ADO recordsets as well, do not claim threads or RAM
    (with ISP Session only) resources as soon as the session is persisted.


    --
    compatible web farm Session replacement for Asp and Asp.Net
    http://www.nieropwebconsult.nl/asp_session_manager.htm

    > Thanks,
    >
    > Anthony.
    >
    >
    Egbert Nierop \(MVP for IIS\), Feb 7, 2006
    #2
    1. Advertising

  3. Thanks for the reply.

    I don't use the session object to store state between requests.

    What I was wondering is whether a page could place an object in the Session
    object then server execute one or more other pages that could maniputlate
    this object. Finally the original page would remove the object from Session
    before completing it's response to the client.

    Between requests Session contains nothing. However I very much suspected
    that even this transistory assignment of an object to the Session would
    irrevocably nail the Session to the work thread.

    :( pity that it would be useful.

    Cheers,

    Anthony.
    Anthony Jones, Feb 7, 2006
    #3
  4. "Anthony Jones" <> wrote in message
    news:...
    > Thanks for the reply.
    >
    > I don't use the session object to store state between requests.
    >
    > What I was wondering is whether a page could place an object in the
    > Session
    > object then server execute one or more other pages that could maniputlate
    > this object. Finally the original page would remove the object from
    > Session
    > before completing it's response to the client.
    >
    > Between requests Session contains nothing. However I very much suspected
    > that even this transistory assignment of an object to the Session would
    > irrevocably nail the Session to the work thread.


    Unless your object is marked as 'Both' and is free-threaded, that would not
    happen.

    And I suspect that Server.Execute does the following.
    It detaches the current session
    Attaches it to the target page,
    executes that page,
    detaches
    reattaches the current page.

    So basically, your system should not hang even if your object is marked as
    'Apartment'.

    After server.execute, remove your object

    'for instance
    Session.Contents.Remove "myobject"
    Egbert Nierop \(MVP for IIS\), Feb 7, 2006
    #4
  5. >So basically, your system should not hang even if your object is marked as
    >'Apartment'.


    Yes once a request has been handed over to a worker thread then any server
    executes are performed by the same thread. I wasn't concerned that it might
    hang.

    >After server.execute, remove your object


    >'for instance
    >Session.Contents.Remove "myobject"


    Thats the key point. Does the line above remove the Sessions affiliation
    with the thread.

    Come to think of it when exactly does the affiliation get created?

    1) When an STA object is first assigned into the Session object

    OR

    2) When a ASP processing of a request is finished and an STA object is found
    to be in the Session object.

    If the 2 then all is well because by then the object is gone (barring
    errors, some work in a custom 500.100 page is probably warranted)

    However I still suspect it is 1 and once in place stays put.

    Anthony.
    Anthony Jones, Feb 7, 2006
    #5
  6. "Anthony Jones" <> wrote in message
    news:...
    > >So basically, your system should not hang even if your object is marked
    > >as
    >>'Apartment'.

    >
    > Yes once a request has been handed over to a worker thread then any server
    > executes are performed by the same thread. I wasn't concerned that it
    > might
    > hang.
    >
    >>After server.execute, remove your object

    >
    >>'for instance
    >>Session.Contents.Remove "myobject"

    >
    > Thats the key point. Does the line above remove the Sessions affiliation
    > with the thread.


    It must be. We are not talking about .NET garbage collection, where the true
    destroyment of an instance happens at any time (unless you use non-default
    approaches)

    If you destroy an object, IIS -will- anticipate on that. The object is
    immediately gone including affiliation.

    Anyway, imagine that I am wrong (unlikely here), still, the thread must
    finish the current page until it would be released for another page request.

    Are you having execution times of ASP pages above say, 5 seconds (per
    request)?

    > Come to think of it when exactly does the affiliation get created?


    I'm not -the- COM expert at this, but you should understand that 'apartment'
    objects, in fact use a hidden window and each hidden window waits and
    processes windows messages.
    As long as the object is active, the thread is kidnapped for the object and
    it won't be released by IIS for another user session.

    > 1) When an STA object is first assigned into the Session object


    true.

    > OR
    >
    > 2) When a ASP processing of a request is finished and an STA object is
    > found
    > to be in the Session object.


    well, if a thread was assigned to a current asp page, that thread won't be
    used for other pages as long as the page did not finish. It has no relation
    with apartment affinity.


    If you -leave- STA objects in the session, you'll have a problem.

    > If the 2 then all is well because by then the object is gone (barring
    > errors, some work in a custom 500.100 page is probably warranted)
    >
    > However I still suspect it is 1 and once in place stays put.
    >
    > Anthony.
    >
    >
    Egbert Nierop \(MVP for IIS\), Feb 8, 2006
    #6
  7. >>>Session.Contents.Remove "myobject"
    >>
    >> Thats the key point. Does the line above remove the Sessions affiliation
    >> with the thread.


    >It must be. We are not talking about .NET garbage collection, where the

    true
    >destroyment of an instance happens at any time (unless you use non-default
    >approaches)


    I guess I've just being a bit lazy.

    Here is an experiment I've just run.

    'VB6 ActiveX dll project "FindThread"
    'Class Info
    Public Property Get ThreadID() as Long
    ThreadID = App.ThreadID
    End Property

    'Thread.asp
    <%
    Dim o
    Set o = Server.CreateObject("FindThread.Info")
    Response.Write o.ThreadID
    %>

    'Affiliate.asp
    <%
    Dim o
    Set o = Server.CreateObject("MSXML2.DOMDocument.3.0")
    Set Session.Contents.Item("test") = o

    Session.Contents.Remove "test"
    'Also tried:-
    'Set Session.Contents.Item("test") = Nothing
    'and:-
    'Session.Contents.RemoveAll

    %>

    In browser:-

    Visit Thread.asp and repeatedly press refresh.
    Returned ID jumps about various threads.

    Visit Affiliate.asp return to Thread.asp and continue pressing refreash
    Returned ID remains the same ID.

    From this is appears that a Session once affiliated remains affiliated
    despite the fact that the Session no longer holds any references to STA
    objects.

    Tried it with the FreeThreaded DOM and the session remained unaffiliated.

    Pity there isn't a Session.Unaffiliate method.

    :(
    Anthony Jones, Feb 8, 2006
    #7
  8. "Anthony Jones" <> wrote in message
    news:...
    >>>>Session.Contents.Remove "myobject"
    >>>
    >>> Thats the key point. Does the line above remove the Sessions
    >>> affiliation
    >>> with the thread.

    >
    >>It must be. We are not talking about .NET garbage collection, where the

    > true
    >>destroyment of an instance happens at any time (unless you use non-default
    >>approaches)

    >
    > I guess I've just being a bit lazy.
    >
    > Here is an experiment I've just run.
    >
    > 'VB6 ActiveX dll project "FindThread"
    > 'Class Info
    > Public Property Get ThreadID() as Long
    > ThreadID = App.ThreadID
    > End Property
    >
    > Pity there isn't a Session.Unaffiliate method.
    >


    Just curious. Does CreateObject("") instead of Server.CreateObject make a
    difference?
    Egbert Nierop \(MVP for IIS\), Feb 8, 2006
    #8
  9. >Just curious. Does CreateObject("") instead of Server.CreateObject make a
    >difference?


    Nope same effect.
    Anthony Jones, Feb 8, 2006
    #9
  10. "Anthony Jones" <> wrote in message
    news:...
    > >Just curious. Does CreateObject("") instead of Server.CreateObject make a
    >>difference?

    >
    > Nope same effect.


    This must be because there is an option 'keep in memory' so the VBruntime is
    not unloaded unless IIS 6 issues a special com function which unloads
    unreferenced com objects.
    Egbert Nierop \(MVP for IIS\), Feb 9, 2006
    #10
  11. >This must be because there is an option 'keep in memory' so the VBruntime
    is
    >not unloaded unless IIS 6 issues a special com function which unloads
    >unreferenced com objects.


    Where is this 'Keep in memory' option?

    Are you talking about the VB 'Retain in memory' compile option?
    This should always set for a DLL to be used in ASP.

    I've never heared of an 'unreferenced com object', a com object that finds
    it has no referrers will destroy itself.

    Are you talking about to the mechanism where the exported function
    DllCanUnloadNow is called and if true the DLL module is unloaded?

    At this point though there are no COM instances of the Classes contained in
    the DLL.

    I don't think any of this standard COM behaviour has anything much to do
    with the Sessions affiliation with a worker thread.
    Anthony Jones, Feb 9, 2006
    #11
  12. "Anthony Jones" <> wrote in message
    news:...
    > >This must be because there is an option 'keep in memory' so the VBruntime

    > is
    >>not unloaded unless IIS 6 issues a special com function which unloads
    >>unreferenced com objects.

    >
    > Where is this 'Keep in memory' option?
    >
    > Are you talking about the VB 'Retain in memory' compile option?
    > This should always set for a DLL to be used in ASP.


    sure

    > I've never heared of an 'unreferenced com object', a com object that finds
    > it has no referrers will destroy itself.
    > Are you talking about to the mechanism where the exported function
    > DllCanUnloadNow is called and if true the DLL module is unloaded?


    sure.

    > At this point though there are no COM instances of the Classes contained
    > in
    > the DLL.
    >
    > I don't think any of this standard COM behaviour has anything much to do
    > with the Sessions affiliation with a worker thread.


    You don't think, I say "it might be".
    The VBruntime is not documented that much and IIS not as well.
    If you want, I can try to ask this to someone who might now.
    Egbert Nierop \(MVP for IIS\), Feb 11, 2006
    #12
  13. >You don't think, I say "it might be".
    >The VBruntime is not documented that much and IIS not as well.
    >If you want, I can try to ask this to someone who might now.


    I'm certain that this is an IIS/ASP specific behaviour.

    I'm also convinced now after my own experimentations that once a session is
    affiliated with a work thread that affiliation sticks and there's nothing an
    ordinary ASP page can do about it.

    It would be nice if an 'Inside IIS/ASP guru' would come along and say 'ah
    yes it does but if you call the API function yadayada you can release the
    affiliation' but I don't think that's likely to happen. :)

    Thanks for your input it's enabled me to thrash through it and gave me the
    motivation to get off my lazy backside and test it for myself.

    Anthony.
    Anthony Jones, Feb 11, 2006
    #13
    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. pfurb

    Microsoft Help: IEExe.exe and STA

    pfurb, Jan 19, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    562
    Jeff B.
    Jan 20, 2004
  2. pfurb
    Replies:
    0
    Views:
    517
    pfurb
    Jan 21, 2004
  3. Crimson_M

    Design Flow: STA to Synthesis

    Crimson_M, Sep 8, 2003, in forum: VHDL
    Replies:
    1
    Views:
    780
    Brian Drummond
    Sep 9, 2003
  4. Replies:
    5
    Views:
    9,743
  5. Daniel Cuculescu

    deadlock when using waitOne in a STA thread

    Daniel Cuculescu, Jun 5, 2008, in forum: ASP .Net
    Replies:
    0
    Views:
    2,048
    Daniel Cuculescu
    Jun 5, 2008
Loading...

Share This Page