This is the first post in a series of articles that will be covering practical topics for developers working with GLASS. For simplicity’s sake all examples in these articles will be written as if you are using the appliance, however, if you are using a Linux install of GLASS, you should be able to adapt the examples to your specific installation. If you want to delve into more detail you should read the GemStone 101 series of articles or dive into our most excellent documentation.

To start things off, I’d like to drive home the notion of shared, persistent session state for Seaside.

We’ll start with a graphic example where we’ll kill off the web server gems in the middle of a session, restart the gems and observe that the user experience can continue uninterrupted.

To give it a try:

  1. Bring up the counter example in your browser (http://localhost/seaside/examples/counter) and click on the ++ link a couple of times.
  2. Shut down the Seaside web server gems (using the GLASS Appliance>>GLASS Components>>Gemstone – Gems>>Stop menu item).
  3. Click on the ++ link after shutting down the gems and you should get a server error – not surprising.
  4. Restart the server gems (using the GLASS Appliance>>GLASS Components>>Gemstone – Gems>>Start menu item).
  5. Press the back button in you browser to bring back the cached browser page.
  6. Finally, click on ++ link and you will see the the value continues to increment as if nothing had happened.

In GLASS, session state is persistent – cached in the Shared Page Cache (SPC) and stored on disk – along with application data. Being able to share session state and application data via the SPC means that multiple web server vms can service HTTP requests without having to account for session affinity. It also means that web server vms can be brought on and off line as needed without interrupting ongoing sessions.

Probably the most important point is that this is done without requiring any extra work on the part of the developer and it is done very efficiently.