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::CME::iLink3::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 lifecycle 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::CME::iLink3::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' lifecycle. 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::CME::iLink3::SessionStorage::storeInboundMessage or OnixS::CME::iLink3::SessionStorage::storeOutboundMessage methods. These numbers should be kept and returned to the Handler through OnixS::CME::iLink3::SessionStorage::inSeqNum() and OnixS::CME::iLink3::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:
- When there is an application-level message, the call order is reversed:
If the user's code throws an exception on any stage, the session becomes disconnected, and subsequent steps are omitted.
Outgoing message handling
Example
class MySessionStorage : public SessionStorage
{
public:
MySessionStorage();
const std::string& id() const override;
void uuid(
UInt64 value)
override;
UInt64 previousUuid()
const override;
void previousUuid(
UInt64 value)
override;
void previousSeqNum(
SeqNumber msgSeqNum)
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;
int MarketSegmentId = 0;
MySessionStorage myStorage;
Session session(sessionSettings, MarketSegmentId,
nullptr, SessionStorageType::Pluggable, &myStorage);
}
- See also
- Pluggable Storage Sample.