Introducing Session Singletons

Singletons have been one of the standout features of 4D 20 R5. Previously, developers could leverage two types of singletons:

  • the process singleton, which is unique to each process but different across processes,
  • and the shared singleton, which is unique across the whole application.

With 4D 20 R7, we are releasing a new type of singleton: the session singleton!

HDI session singletons

What Are Session Singletons?

Session singletons are shared within an entire session but vary between sessions. They are particularly useful in web environments where one user’s requests are handled by different processes each time. In client-server environments, session singletons simplify creating one singleton per user on the server, eliminating concerns about which process is using it.

Sessions in 4D

There are 4 types of sessions in 4D:

  1. Client-server sessions are created on the 4D Server whenever a new user connects with a 4D Remote
  2. Web sessions, created by the web server to handle a user’s HTTP requests, are only available if the scalable sessions have been activated.
  3. REST sessions, created by the REST server to handle the REST requests of a user
  4. The stored procedure session is a session of the 4D Server that handles the execution of all stored procedures

A fifth edge case occurs when no session exists at all. It only happens if you run 4D Mono and execute code outside any web/REST request.

A classic use case: the item inventory

Session singletons shine in use cases like shopping carts, list of elements: the item inventory. For example, consider an item inventory where each user’s inventory is unique:

//class ItemInventory
    property itemList : Collection:=[]

session singleton Class constructor()

shared function addItem($item:object)
    This.itemList.push($item)

By defining the class ItemInventory as a session singleton, every sessionand therefore every userhas their own ItemInventory. Accessing the user’s ItemInventory is as simple as with any other type of singleton:

$myItemInventory:=cs.ItemInventory.me

This will return the ItemInventory of the current session from anywhere in the application. Modifying this ItemInventory, by adding or removing items for example, will only modify the current session’sand therefore current user’sinventory.

Key Considerations for Session Singletons

Shared classes:

The most important thing to understand is that session singletons are shared classes, as they are used by multiple processes.

Shared sessions:

Last but not least: If you reuse the same cookie for a web connection and a REST connection you’ll access the same session (which will switch from a web session to a REST session) and as such the same session singleton.

Conclusion

In summary, session singletons provide a simple and efficient way to manage user-specific data across different sessions in 4D. This new feature offers an easy, scalable solution for building organized applications that efficiently manage data across sessions.

If you have any questions or need assistance, feel free to join the discussion on the 4D forum.

Nicolas Brachfogel
Product Owner & Senior Developer - Nicolas Brachfogel joined 4D in 2017 as senior developer (4D Server and networking) and as Product Owner to manage the 4D version on Apple Silicon. He is tasked with the redaction of user stories and functional specifications, as well as the verification that the new features are in line with customers' needs. With a degree from Institut Supérieur d'Informatique Appliquée Paris (INSIA), Nicolas started his career as a software developer in 2001. After many years of development in Java and C++, he specialized himself in client-server development in the video game industry. As a developer/software architect, he worked on the server architectures of many games (Dofus Arena, Drakerz, Trivial Pursuit Go !).