[plt-scheme] more questions about plt web server

On Jan 7, 2005, at 3:42 PM, Larry White wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Hi,
>
> First, thanks for the help so far.  It's greatly appreciated.   This
> is the most fun i've had coding since i got paid to work in smalltalk.

:-)

>
> 1. When writing servlets, what do you do with resources that should
> have application scope- things like a global hashtable for sessions or
> a db connection pool that need to persist across servlets,
> continuations, etc.  For the record, i can't use a single servlet with
> continuations to represent an entire session with my app because it
> would be too large.

I will respond assuming you will ultimately be using the v299 version 
of the
server but for the v209 server the answer would be similar.

For performance reasons, the server caches servlets. Internally, a 
servlet
is represented as a signed unit which may be invoked many times.
This signed unit is closed over a namespace which is created the very 
first
time the servlet is loaded from the file system. The namespace will 
last until
the servlet is refreshed and at that time a subsequent request for that 
servlet
will load it again thus creating a new namespace. Each invocation of a 
servlets
signed unit is a servlet-instance, and all such servlet-instances are 
thus
closed over the same namespace.  This namespace should store all 
bindings for
variables that you want at "application scope".

For module servlets:
The module is loaded and then the start function is dynamically 
required.
Internally, the signed unit representing the servlet is just a wrapper 
for
the start function. What this means is that all top-level bindings for 
the module
and all required modules will be at application scope.

For signed unit servlets:
Here you build the signed unit explicitly, whatever bindings this signed
unit is closed over are at application scope. Pretty much everything 
that
is at top level.

There are two custodians to be aware of when managing resources:
A connection custodian.
A servlet-instance custodian.

The connection custodian manages the TCP connection but doesn't
manage anything you're worried about. For http 1.0 the connection
custodian lasts (roughly) from the most recent request until the next
response is sent and then it is shut down. For http 1.1 it will last for
multiple request/response pairs.

A new servlet-instance custodian is created every time a user accesses
the servlet using a URL that does not represent a continuation. 
Typically,
this is the user's first interaction with the servlet. The 
servlet-instance custodian
manages all the continuations associated with this instance (i.e. 
typically
all the continuations created by a single user) and all resources that 
are
created within the dynamic extent of the instance that are not at 
application
scope. The servlet-instance custodian will eventually time out, and this
is the primary method for managing continuation lifetimes. By default,
the timeout is set to the default-servlet-timeout value in the 
configuration
file.  After the servlet is created, the timeout is typically changed 
to a more
reasonable value. For module servlets, the value of the global 'timeout
variable is used. Signed unit servlets can use adjust-timeout to change
this value.

When the servlet-instance custodian is shut down, it will not effect
resources that have application scope. So, for example, many
continuations can come and go during a single database connection
that was established at top-level scope.

> 2. The smalltalk days referred to above came to an end because our
> chosen smalltalk used language threads in such a way that the entire
> application blocked on external function calls - like a database
> access for example.  Since that was where the web app spent most of
> its time, it could only handle one user at a time.  (I hear earlier
> versions of python had the same issue.)   Please tell me this isn't
> the case with mzscheme.
>

This isn't the case with mzscheme.
  :-)

> Thanks again.
>