The session ownership subsystem is an optional Rhino platform extension with the primary purpose of allowing SLEE services and resource adaptors on a given node to claim ownership of a particular thing such as an individual SLEE activity or a complete identifiable session.
It’s intended for use in a multi-node Rhino cluster where events related to a given session could be delivered to a node that does not have state for that session. In order to keep the state for the session coherent, the session ownership subsystem can be used to determine the current session owner, allowing components to redirect events to the owning node.
The session ownership subsystem supports both blind-write and compare and set (CAS) operations for the creation, update, and removal of session ownership records.
Session ownership records are addressed by a primary key as well as any number of additional secondary keys. In addition, records contain a sequence number, a set of URIs identifying the owner(s) of the record, and a set of user-defined attributes.
High-level usage
The general approach in using the session ownership store is as follows:
-
When a SLEE component detects a new session, whatever "session" means to the component, is about to begin, the component attempts a CAS create operation in the session ownership subsystem to claim ownership of the session.
-
If the operation completes successfully, the component continues on normally and processes the session.
-
The component can update the session ownership record at any time as needed. It may do so either as blind writes or CAS updates (recommended) based on the existing record’s sequence number.
-
When a session ends, the component removes the session ownership record.
-
If a CAS operation fails because some other node has claimed ownership of the session, the component could:
-
proxy the request sideways to the current session owner, if the owner is still deemed to be alive; or
-
take over ownership of the session and handle the request if the current owner is deemed to no longer exist.
-
Components
The session ownership subsystem consists of three main components:
-
Session ownership store — This is responsible for processing session ownership operation requests from the higher application-level APIs and (typically) interacting with an external storage medium for the persistence of session ownership records.
-
Session ownership facility — This is the application-level API available to resource adaptors for interaction with the session ownership subsystem.
-
Session ownership resource adaptor type — This is the application-level API available to SBBs for interaction with the session ownership subsystem.
