Pluggable Session Storage

Pluggable session storage is the storage implemented by the user.

For example, it could be used to implement High-Availability (HA) Solutions:

One can implement a Pluggable Session Storage that stores data to shared storage. If one server fails and another reserve server activates, the Handler can restore session states from the shared storage.

Such storage should implement the OnixS::B3::BOE::SessionStorage interface.

Implementing Pluggable Storage

There are a few basic rules that should be applied to the implementation of Pluggable Storage.

• The user should manage the life-cycle of the storage. The Handler treats the instance of a Pluggable Storage as a "foreign" object and never attempts to delete it. On the other hand, there is a strong requirement to keep storage instance valid until the OnixS::B3::BOE::Session instance is destroyed.
• Be as fast as possible. The Pluggable Storage is a part of the message send/receive path, so it has a direct effect on the sending/receiving latency and overall throughput of the system.
• Avoid throwing exceptions. Exceptions thrown from Pluggable Storage callbacks immediately break a session.
• Don't make assumptions about the parameters' life-cycle. Whenever you need to keep such data for separate usage, you should make copies of messages or memory blocks and store them in an appropriate place, but don't keep raw pointers, passed to callbacks.
• No synchronization is required. The Handler manages all synchronization issues, so all methods of Pluggable Storage are called sequentially.
• Track message numbers when the message is logged. Message sequence numbers should be tracked while messages are logged, i.e. during OnixS::B3::BOE::SessionStorage::storeInboundMessage or OnixS::B3::BOE::SessionStorage::storeOutboundMessage methods. These numbers should be kept and returned to the Handler through OnixS::B3::BOE::SessionStorage::inSeqNum() and OnixS::B3::BOE::SessionStorage::outSeqNum() calls.

Call Order of Pluggable Storage Methods

This section explains how different methods of Pluggable Storage are called in different situations.

Incoming message handling

• When there is a session-level message, the following methods are called:
  • OnixS::B3::BOE::SessionStorage::storeInboundMessage
  • OnixS::B3::BOE::SessionListener methods, if the listener is present
• When there is an application-level message, the call order is reversed:
  • OnixS::B3::BOE::SessionListener methods, if the listener is present
  • OnixS::B3::BOE::SessionStorage::storeInboundMessage.

If the user's code throws an exception on any stage, the session becomes disconnected, and subsequent steps are omitted.

Outgoing message handling

• OnixS::B3::BOE::SessionListener methods.
• OnixS::B3::BOE::SessionStorage::storeOutboundMessage.

Example

class MySessionStorage : public SessionStorage
{
public:
    MySessionStorage();

    const std::string& id() const override;

    UInt64 sessionVerId() const override;

    void sessionVerId(UInt64 value) override;

    SeqNumber inSeqNum() const override;

    void inSeqNum(SeqNumber msgSeqNum) override;

    SeqNumber outSeqNum() const override;

    void outSeqNum(SeqNumber msgSeqNum) override;

    bool negotiated() const override;

    void negotiated(bool status) override;

    Timestamp sessionCreationTime() const override;

    void sessionCreationTime(Timestamp) override;

    void close(bool doBackup = false) override;

    void storeInboundMessage(const NetworkMessage& message, SeqNumber msgSeqNum, Timestamp messageReceivingUtcTimestamp = Timestamp()) override;

    void storeOutboundMessage(const NetworkMessage& message, SeqNumber msgSeqNum, Timestamp messageSendingUtcTimestamp = Timestamp()) override;

    void flush() override;

    void warmup(size_t messageSize, Timestamp ts) override;
};
};

void pluggableStorage()
{
    SessionSettings sessionSettings;

    MySessionStorage myStorage;

    Session session(sessionSettings, nullptr, SessionStorageType::Pluggable, &myStorage);
}

See also

Pluggable Storage Sample