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.)

Restriction:

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.

When you supply a durable name in the subscribe call, the call resolves it to a unique durable name in two phases:
  1. 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.
    Note: Subscriber name mapping is an advanced topic.
  2. 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).
These anomalous situations trigger the subscription listener's error callback:
  • 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.

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.