Library Zone Articles
External Articles
Byte Size

Discovery Zone Catalogue
Diary
Links
Bookstore
Interactive Zone Ask the Gurus
Discussion Groups
Newsletters
Feedback
Etc Cartoons
Humour
COMpetition
Advertising
ASP Web Ring ASP Web Ring
Click here
The Developer's Resource & Community Site
COM XML ASP Java & Misc. NEW: VS.NET
International This Week Forums Author Central Find a Job

Session state and 'lock downs'.

This article is a response to a question on the dev-asp list by a member. The reader wanted information on Session State.

I have a question about Session state. Does this refer only to "objects" that are held in Session variables? What if I am holding a number in a Session variable that I pass to my COM object, does this still 'lock-down' the thread? Is it just the possibility of using the Session object that causes these lock-downs to occur?

Response: Storing scalars (numbers and strings) in the ASP Session object works fine. There are no gotchas.

Storing large arrays in the Session and Application object can lead to performance problems. The semantics of VBScript and JScript require that a temporary copy be made of the entire array, *when stored in the Session/Application object*, whenever you want to dereference an element of that array.

The problem that people have been talking about refers to storing Apartment-threaded objects in the ASP Session object. Apartment-threaded objects have thread affinity and can only be validly accessed on the STA thread they were created on. If you need to access such an object from a different apartment, you need to use a proxy, which marshals the data from the calling apartment to the owning apartment. You have two context switches and this is far, far slower than making a direct vtable call.

We chose instead to "lock down" the ASP Session to the creating thread, if an Apartment-threaded object has been stored in the Session object. All calls to the object are now direct vtable calls, which is considerably faster. It also simplifies matters significantly, and avoids potential deadlocks. There some costs to this approach, as outlined in my earlier message.

To avoid locking down ASP Sessions, you must use Both-threaded components *that aggregate the Free-Threaded Marshaler*. If you're storing objects in the ASP Application object, they should definitely be Both+FTM objects, as Apartment-threaded objects have huge costs at Application scope. The object is created on a special STA, so all accesses are marshaled across to the STA. Worse, all accesses are serialized, which kills concurrency. In IIS 5.0/Windows 2000, you can use Neutral components instead of Both+FTM.


Power your site with idr newswire

Contribute to IDR:

To contribute an article to IDR, a click here.

To contact us at IDevResource.com, use our feedback form, or email us.

To comment on the site contact our webmaster.

Promoted by CyberSavvy UK - website promotion experts

All content © Copyright 2000 IDevResource.com, Disclaimer notice

WTL Architecture by Richard Grimes

Learn C#

Join the Developers Webring

Visit our NEW WTL Section