Persistence
Your eFTL applications can use the persistence features of either the FTL persistence server or the EMS server.
Coordination
Persistence depends on proper configuration of the eFTL server channel, and of the FTL persistence server or EMS server, corresponding to the channel's message infrastructure. Developers must coordinate with administrators to agree on the requirements for this configuration. Complete the appropriate coordination forms together.
Durable Subscriptions
A durable subscription is a subscription that persists even when the application is not running. The FTL persistence server or the EMS server maintains the durable subscription on behalf of the application.
Unsubscribe
The unsubscribe call deletes the durable subscription. The server discards all messages that it holds for the subscription.
FTL Persistence
The FTL channel must be configured for persistence. (See "Configuring Persistence for an FTL Channel" in TIBCO eFTL Administration.)
eFTL programs can subscribe to dynamic or static durables of any type: standard, shared, or last-value durables.
- Static If the channel definition includes a static durable mapping, and it maps the durable name to a static durable in the channel's persistence store, then the result is a subscription to that static durable.
- Dynamic If the first phase did not result in a valid static durable, the subscribe call attempts to create and subscribe to a dynamic durable.
- If the call does not specify the durable type property, and the channel definition includes a default durable template, then the call creates a durable using that template.
- If the call specifies the durable type property, and the channel definition includes a dynamic durable template corresponding to that type, then the call creates a durable using that template.
The result is a subscription to a dynamic durable with a unique durable name (see the section "Dynamic Durable Names," which follows).
- You supply a durable name but the FTL channel is not configured for persistence.
- The FTL channel is configured for persistence but you do not supply a durable name.
- The subscribe call cannot resolve the durable name you supply to either a static or a dynamic durable.
- The channel definition does not specify a dynamic durable template for the durable type of the subscribe call.
See also Last-Value Durables.
EMS Persistence
The EMS server must be configured to support concatenated durable names.
Every subscribe call results in a durable subscription to a concatenated durable name (see the section "Dynamic Durable Names," which follows).
Dynamic Durable Names
For shared durables and last-value durables, the name of the dynamic durable is the durable name that program supplies in the subscribe call.
For standard durables, the client library forms a unique concatenated durable name by prefixing the client ID string and a period (.) character to the durable name the program supplies in the subscribe call.
Concatenated names must not exceed the maximum name length. See Length Limit.
Client ID
The client ID indicates the particular process instance of the application program that created the durable subscription. Usually this ID represents either the user of the application or a specific mobile device. Two client processes cannot use the same client ID at the same time.
You may supply the client ID in the connect call. For long-term persistence, it is good practice to explicitly supply a client ID.
If you do not supply a client ID, the connect call assigns a unique client ID. However, such assigned ID strings can provide only short-term persistence. If the client process disconnects from the eFTL server and then reconnects, an assigned ID preserves the durable subscription through that time gap. However, if the application restarts, then the durable subscription is not available.