A stateless servlet should provide the following exports:

If it is not provided, it defaults to default-stuffer .

If it is not provided, it defaults to (create-none-manager #f).

The web-server/base language exports all of the functions and syntax from racket/base and nothing else.

The web-server language exports all of the functions and syntax from the following libraries: racket, net/url, web-server/http, web-server/http/bindings, web-server/lang/abort-resume, web-server/lang/web, web-server/lang/native, web-server/lang/web-param, web-server/lang/web-cells, web-server/lang/file-box, web-server/lang/soft, web-server/dispatch, and web-server/stuffers. Some of these are documented in the subsections that follow.

3.2Usage Considerations🔗 i

This process allows the continuations captured by your servlet to be serialized. This means they may be stored on the client’s browser or the server’s disk.

This means your servlet has no cost to the server other than execution. This is very attractive if you’ve used Racket servlets and had memory problems.

This means your server can restart in the middle of a long running Web interaction without the URLs that have been shared with the client expiring. This is very attractive if you’ve used Racket servlets and had session timeout problems.

This process is defined on all of Racket and occurs after macro-expansion, so you are free to use all interesting features of Racket. However, there are some considerations you must make.

First, this process drastically changes the structure of your program. It will create an immense number of lambdas and structures your program did not normally contain. The performance implication of this has not been studied with Racket.

Second, the defunctionalization process is sensitive to the syntactic structure of your program. Therefore, if you change your program in a trivial way, for example, changing a constant, then all serialized continuations will be obsolete and will error when deserialization is attempted. This is a feature, not an error! It is a small price to pay for protection from the sorts of errors that would occur if your program were changed in a meaningful way. If you use the default-stuffer or web-server/stuffers/hash, then whenever you change your servlet’s code, you can safely delete all saved continuations, because they won’t be used any longer.

Third, the values in the lexical scope of your continuations must be serializable for the continuations itself to be serializable. This means that you must use define-serializable-struct rather than define-struct , and take care to use modules that do the same. Similarly, you may not use parameterize , because parameterizations are not serializable.

Fourth, and related, this process only runs on your code, not on the code you require . Thus, your continuations—to be serializable—must not be in the context of another module. For example, the following will fail with an "unsafe context" exception:

Fifth, the store is not serialized. If you rely on the store you will be taking huge risks. You will be assuming that the serialized continuation is invoked on the same server before the server is restarted or the memory is garbage collected.

This process is derived from the papers Continuations from Generalized Stack Inspection by Pettyjohn et al. in 2005, Automatically RESTful Web Applications, Or Marking Modular Serializable Continuations by Jay McCarthy in 2009, and The Two-State Solution: Native and Serializable Continuations Accord by Jay McCarthy in 2010, We thank Greg Pettyjohn for his initial implementation of this algorithm.

3.3Serializable Continuations🔗 i

3.4Native Interfaces🔗 i

3.5 Stateless Web Interaction🔗 i

3.6 Stateless Web Cells🔗 i

3.7 File Boxes🔗 i

3.8 Stateless Web Parameters🔗 i

3.9Soft State🔗 i

3.10Stuffers🔗 i

The web-server language provides serializable continuations. The serialization functionality is abstracted into stuffers that control how it operates. You can supply your own (built with these functions) when you write a stateless servlet.