IDevResource.com - ASP Byte Size: Session state and 'lock downs'.

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.

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.