Persistence: Stores and Durables

Stores and durables provide persistent message interest and persistent message streams.

For an intuitive introduction and terminology, see “Persistence: Stores and Durables” in TIBCO FTL Concepts.

• Purposes of Persistence
  The persistence infrastructure of stores and durables can serve three purposes: delivery assurance, apportioning message streams, and last-value availability. These purposes correspond to three types of durables: standard durables, shared durables, and last-value durables.
• Persistence Architecture
  Persistence is flexible. Administrators can tailor various aspects of persistence to meet the needs of applications.
• Coordination for Persistence
  Administrators and application developers must coordinate the details of durables.
• Stores for Delivery Assurance
  
• Stores for Apportioning Message Streams
  
• Stores for Last-Value Availability
  
• Default Durable
  You can use the default durable to add delivery assurance to any application, even applications that do not explicitly supply a durable name or a subscriber name in their create subscriber calls.
• Durable Behavior
  Administrators configure the behavior of a durable and its interaction with durable subscribers.
• Persistence Servers and Clusters
  A persistence server is a process that implements one or more persistence stores. Several servers can cooperate in a persistence cluster.
• Configuring Persistence
  The realm definition schematic in the following diagram indicates five configuration tasks for persistence stores and durables. (Numbers in the diagram correspond to the task steps that follow.)
• Persistence Server (tibstore) Command Line Reference
  Administrators use the tibstore command line executable to start persistence server processes.
• Starting a Persistence Server
  Administrators have full responsibility for persistence server operation.
• Stopping a Persistence Server
  To stop an individual persistence server, terminate the process.
• Persistence Monitoring and Management
  
• Before Forcing a Quorum
  When a cluster contains enough reachable servers, but not enough non-empty servers to form a quorum, an administrator may force a quorum. Read this topic first.
• Saving and Loading Persistence State
  The persistence GUI includes a facility to save the content of a server’s persistence stores to a file. When a server starts, it can load its initial state from that file. You can use this facility to migrate a persistence cluster to a new physical location, or for nightly backups.
• Clock Synchronization, Affiliated Realm Servers, and Persistence
  Persistence servers depend on clock synchronization among affiliated realm servers.

Copyright © Cloud Software Group, Inc. All rights reserved.