Session Management

From RemObjects Wiki

Jump to:navigation, search

This is a RemObjects SDK Architecture topic
Feel free to add your notes to this topic below.


Sometimes it is sensible to maintain a little bit of client state between calls, even if your application is designed for Statelessness. For example, you might want to implement access control and provide a Login method to initiate authentication, rather than retransmitting the password for each and every remote call. This can be achieved through so called Sessions that allow you to store per-client information outside of your service objects. It will be up to your service implementation to store this data inside the session before a call finishes, and obtain it again, when needed, in subsequent calls.

RemObjects SDK passes a so called Client ID (sometimes also referred to as Session ID) back and forth for each call made from a client to the server. This client ID is a GUID that uniquely identifies each client and allows the server to determine which calls are received from the same client.

Contents

Sessions

Sessions can be used to store data for a specific client ID and later retrieve the same data again. To make this easy, the base classes for new services (RemObjects.SDK.Server.Service for .NET and TRORemoteDataModule for Delphi) encapsulate the communication with the underlying session manager and expose properties to check if session data exists, and to store and retrieve data from the session.

Session Managers

Session data is stored and maintained by a global Session Manager instance. Different implementations of session managers are provided to suit different needs, for example to store session data in memory or a back-end database:

The session manager architecture is flexible and extensible, allowing you to easily implement custom session managers to suit your specific needs, if necessary.

Session Timeouts

Application servers are usually intended to run continuously 24/7, without ever shutting down. As such, session memory would continue to grow slowly but steadily over the lifetime of a server, as new clients connect and disconnect. What's more, in most scenarios client applications will not maintain their unique client ID across restarts (although such functionality is possible, if required), so each restarted client will create a new session.

To avoid the server memory (or session database) filling up with stale and unused session data, Session Managers implement automatic session timeouts. The session managers keep track of sessions as they are accessed, and will destroy any session that has not been accessed for a given amount of time (by default 20 minutes).

Client applications that are expected to run longer periods of time without communication with the server should either implement regular "keep-alive" server calls to keep the session from expiring or - preferred - handle expired sessions gracefully, for example by handling the OnLoginNeeded event on the channels.

Session Manager Components

See Also


Ro-48.png

Product: RemObjects SDK
Available Editions: RemObjects SDK for .NET, Delphi and Xcode

GlossaryArchitectureArticlesFeaturesLibrarySamples

Navigation
products
hubs
special
Toolbox