STA object in Session and Thread Affiliation

"Anthony Jones" <An*@yadayadaya da.com> wrote in message
news:e6******** ******@TK2MSFTN GP09.phx.gbl...

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.

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" <An*@yadayadaya da.com> wrote in message
news:u8******** ******@TK2MSFTN GP15.phx.gbl...

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.Content s.Remove "myobject"

>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.Conten ts.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" <An*@yadayadaya da.com> wrote in message
news:Oz******** ******@TK2MSFTN GP09.phx.gbl...

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

>>>Session.Cont ents.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 truedestroyment 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.CreateOb ject("FindThrea d.Info")
Response.Write o.ThreadID
%>

'Affiliate.asp
<%
Dim o
Set o = Server.CreateOb ject("MSXML2.DO MDocument.3.0")
Set Session.Content s.Item("test") = o

Session.Content s.Remove "test"
'Also tried:-
'Set Session.Content s.Item("test") = Nothing
'and:-
'Session.Conten ts.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.Unaffil iate method.

:(

"Anthony Jones" <An*@yadayadaya da.com> wrote in message
news:uK******** ******@TK2MSFTN GP14.phx.gbl...

Session.Con tents.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.Unaffil iate method.

Just curious. Does CreateObject("" ) instead of Server.CreateOb ject make a
difference?

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

difference?

Nope same effect.

"Anthony Jones" <An*@yadayadaya da.com> wrote in message
news:es******** ******@TK2MSFTN GP15.phx.gbl...

Just curious. Does CreateObject("" ) instead of Server.CreateOb ject 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.