Subj : Http Sessions - was - RE: Different ways to embed SpiderMonkey
To   : netscape.public.mozilla.jseng
From : Damian Slee
Date : Mon Sep 13 2004 10:45 am

>>Implementing session is not as easy as header. Internally, all sessions on server 
>>could be  stored in a global_sessions map<string,
>>global_sessions["SEESION_ID"]...) from our map. My troubles mostly 

I am looking at implementing something very similar.  Initially I was thinking like MS ASP.  (This is what I what playing with last week)

But now I'm thinking that I will have a "session" global object  for each user, with script session.asa run on it.  Each time a ASP script is required to run for a user, a new global object is created to run the asp script on, the parent of this is the session global object, which has had session.asa run on it.  So your session variables are just javascript variables in the session object.  You don't have to manage it natively, other than maintain a root for the session object/script.  The ASP global object
 is left to GC at the end of its execution.  The Session global object is kept for the life of the session.

I'm not sure if it is needed for threadsafeness, but all asp pages for the same user/session, could be made to run serialized. Ie not run in parallel.  So there is no concurrency on that session global object.

I'm also planning on having an Application global object (with global.asa run upon it), which all the session have as a parent, but I'm not sure on the thread safeness of this???  Its very possible that scripts from differing threads could be accessing it.  1 context/thread.

Further the application and asp scripts require access to the standard classes, as well as a DBRecordset object to access the database.  Do you define the one in the application global object, so asp scripts can access it through its parents parent (session -> application)??  Or do you define a local copy for each?

Anyone want to comment on this further?

Answering the other questions;
>>should there be a new JSContext allocated for every client being processed
No 1 context/thread.  You can call JS_SetGlobalObject on the context X when you want to run a script on it against global object Y.  So you can have multiple global objects/context for each instance of script execution you require.  But you don't necessaryilly require 1 context/global object, unless you NEED it to run in a loop for ever.

>>Will it be possible to access that object from another context (B_c) ???
Yes, if it is all on the same runtime.  If nothing is 'holding a reference of some kind' to a JS object of some kind, then it, and what ever it contains will be GC'ed, unless you root it.  When I'm testing/debuging, I like to add JS_GC() everywhere, brings the problems I have missed to the surface quicker.


Thanks,
damian

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.756 / Virus Database: 506 - Release Date: 8/09/2004

.