STA object in Session and Thread Affiliation

[Anthony Jones]

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.

 

[Egbert Nierop \(MVP for IIS\)]

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.

 

[Anthony Jones]

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.

 

[Egbert Nierop \(MVP for IIS\)]

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"

 

[Anthony Jones]

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.

 

[Egbert Nierop \(MVP for IIS\)]

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.



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.

 

[Anthony Jones]

Session.Contents.Remove "myobject"

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.

 

[Egbert Nierop \(MVP for IIS\)]

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?

 

[Anthony Jones]

Just curious. Does CreateObject("") instead of Server.CreateObject make a

difference?

Nope same effect.

 

[Egbert Nierop \(MVP for IIS\)]

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.

 

[Anthony Jones]

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.

 

[Egbert Nierop \(MVP for IIS\)]

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.

 

[Anthony Jones]

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.