Choose session storage according to the state and message history your application must recover after a restart. Set the storageType parameter of the OnixS::FIX::Session::Session constructor to the corresponding OnixS::FIX::SessionStorageType value. FileBased is the default.

File-based session storage uses the directory configured by OnixS::FIX::EngineSettings::logDirectory; the default is MsgStorage under the application's current working directory. The Engine log is separate from session storage: choosing MemoryBased for a session does not move the Engine log into memory.

Comparing storage types

Requirement	FileBased	AsyncFileBased	MemoryBased	Pluggable
State after restart	Restored from existing files.	Restored from existing files; queued writes can be lost after an abrupt stop.	Not retained.	Defined by the implementation.
Replay history	Subject to logging, retained files, and resend-queue limits.	The same limits apply; unwritten messages are unavailable.	Available only during the process lifetime and subject to logging and resend-queue limits.	Defined by the implementation and the Engine's resend rules.
Write path	File operations run on the message-processing path.	File operations run on a storage thread; queue backpressure can pause message processing.	Uses process memory.	Defined by the implementation.
Recovery requirement	Preserve the files and use orderly shutdown.	Use orderly shutdown and reconcile state after an abrupt stop.	Restore state externally or agree a sequence reset.	Follow the implementation's recovery contract.

See File-Based Session Storage, Asynchronous File-Based Session Storage, Memory-based Session Storage, and Pluggable Session Storage for setup details. For the shutdown order, see Shutting down the whole Application.

Write completion and replay

Returning from OnixS::FIX::Session::send is not a durability checkpoint. With AsyncFileBased storage, file operations can still be queued. Synchronous file writes also do not guarantee device synchronization.

OnixS::FIX::Session::flushSessionStorage behaves as follows:

For FileBased and AsyncFileBased, it flushes internal buffers. When syncData is true, it also synchronizes the current summary file with the storage device.
For MemoryBased, syncData has no effect.
For Pluggable, the method calls OnixS::FIX::ISessionStorage::flush without passing syncData; the implementation defines its own durability behavior.

For built-in file storage, even when syncData is true, persistence depends on the filesystem and storage device honoring the synchronization request.

For asynchronous queue and failure behavior, see Queue backpressure and failure reporting.

Persistence does not by itself make a message available for replay. Logging options and filters can exclude outbound messages, and the resend queue can exclude older messages. The counterparty must request the message, and it must meet the callback and eligibility rules in Resending Messages. See also Customizing Logging and Resending queue size.

For segmented file storage, missing required segments can prevent session creation. See Checking integrity of segmented File-Based Storage for the session-creation behavior.

Use Restoring Session State from Log Files to continue a session after restart, recover after a crash, or start again with agreed sequence numbers.