Classic ASP Store objects in the session object

Question

I am new to classic ASP and I need to code a web application in classic asp because the customer wants it to be in classic asp. :(

Anyways! here is my question:

Answer 1

I can't explain why your code doesn't work looks fine to me.

The object is created in a script context which is subsequently torn down after the request is complete. Hence whilst the type name is available the object's function is broken.

I can tell you its not a good idea to store objects in the Session even those not created in script.

Most objects used in ASP exist in a single thread. Once created only the thread that created the object may access the object. To cope with this once you have stored an object in the session ASP affiliates the session with the specific worker thread that created it the object.

When a subsequent request for that session arrives it must now be handled by its specific worker thread. If that thread happens to be busy working for some other request the sessions request is queued, even if there a plenty of other available worker threads.

The overall effect is to damaging the applications scalability where the work load can become unevenly distributed across the worker threads.

Answer 2

I am to lazy to test it for you, but

Instead of:

set Session("somePerson") = aPerson

Try:

Set Session("somePerson") = Server.CreateObject(aPerson)

Answer 3

I would create a COM object that looks like your Person class with VB6. Then store that. The code is very similar.

Pete's method probably works.

Answer 4

Set session data like this:

set Session.Contents("UserData") = UserData

and then get it like this:

Session.Contents("UserData.UserIsActive")

Answer 5

Shouldn't it be

If IsObject(Session("somePerson")) = true Then
    set mySessionPerson = Session("somePerson")

Answer 6

You can do this but you have to be a bit sneaky. My understanding of it is when you store a home baked object in Session is keeps all the data but loses all the functionality. To regain the functionality you have to "re-hydrate" the data from the session.

Heres an example in JScript for ASP:

<%@ Language="Javascript" %>
<%

function User( name, age, home_town ) {

    // Properties - All of these are saved in the Session
    this.name = name || "Unknown";
    this.age = age || 0;
    this.home_town = home_town || "Huddersfield";

    // The session we shall store this object in, setting it here
    // means you can only store one User Object per session though
    // but it proves the point
    this.session_key = "MySessionKey";

    // Methods - None of these will be available if you pull it straight out of the session

    // Hydrate the data by sucking it back into this instance of the object
    this.Load = function() {
        var sessionObj = Session( this.session_key );
        this.name = sessionObj.name;
        this.age = sessionObj.age;
        this.home_town = sessionObj.home_town;
    }

    // Stash the object (well its data) back into session
    this.Save = function() {
        Session( this.session_key ) = this;
    },

    this.Render = function() {
        %>
        <ul>
            <li>name: <%= this.name %></li>
            <li>age: <%= this.age %></li>
            <li>home_town: <%= this.home_town %></li>
        </ul>
        <%
    }
}

var me = new User( "Pete", "32", "Huddersfield" );
me.Save();

me.Render();

// Throw it away, its data now only exists in Session
me = null;

// Prove it, we still have access to the data!
Response.Write( "<h1>" + Session( "MySessionKey" ).name + "</h1>" );

// But not its methods/functions
// Session( "MySessionKey" ).Render(); << Would throw an error!

me = new User();
me.Load();  // Load the last saved state for this user

me.Render();

%>

Its quite a powerful method of managing saving state into the Session and can easily be swopped out for DB calls/XML etc. if needed.

Interesting what Anthony raises about threads, knowing his depth of knowledge I'm sure its correct and something to think about but if its a small site you will be able to get away with it, we've used this on a medium sized site (10K visitors a day) for years with no real problems.