Classic ASP Store objects in the session object.

Question

Hi All,

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:

When I have a object of a class called person:

Class Person
 Private m_sFirstName

 Public Property Get firstName
 firstName = m_sFirstName
 End Property

 Public Property Let firstName(value)
   m_sFirstName = value
 End Property

End Class


set aPerson = new Person
Person.firstName = "Danny"

set Session("somePerson") = aPerson

---

So far so good...

On the next request , I try to read the session var like :

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

      Response.Write(TypeName(myTest)) // will output "Person" 
      Response.Write(mySessionPerson.firstName) // will output "Object doesn't support this property or method: 'mySessionPerson.firstName'
End If

Any ideas about what is going would be of great help.

Answer 1

Shouldn't it be

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

Answer 2

This is because objects in ASP Classic are not serializable.

Here is an article on a way to simulate serializing objects in ASP Classic.

http://decav.com/blogs/andre/archive/2007/02/12/1073.aspx

Look at Saving ASP VBScript "Objects" to Session about half way down the page.

Answer 3

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 4

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.

Answer 5

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.