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 session–and therefore every user–has 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’s–and therefore current user’s–inventory.

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.