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 static durables of any type: standard, shared, or last-value durables.
However, eFTL programs can create and subscribe to dynamic durables only if the template specifies the type as a standard durable. For shared and last-value semantics, use static 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, and the channel definition includes a dynamic durable template, then the result is a subscription to a dynamic durable with a unique concatenated durable name (see the section "Concatenated Durable Names," which follows).
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 "Concatenated Durable Names").
Concatenated Durable Names
The client library forms a unique concatenated durable name by prefixing the client ID string and a period (.) character to the program's durable name (as supplied in the subscribe call).
The concatenated name 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.