Federated Deployment

TRANSIENT durability is typically exploited when using ‘federated-deployment’ where federations have a configured durability-service that maintains non-volatile data for late-joiners even when no applications are running.

Single Process

In case you’re using standalone-deployment (aka ‘single-process) you can still use TRANSIENT data but that then relies on applications being active that have configured a durability-service (in their ‘ospl’ configuration) and where the historical data retained by an application is ‘tied’ to the lifecycle of that application (so when all apps are ‘gone’, there won’t be any retained historical data).

Another consequence is that each application potentially retains a copy of ALL historical data, whether its interested in it or not. You may want to use TRANSIENT_LOCAL data which is more suitable for standalone deployment as that data is (solely) maintained by the producer (writer) of that TRANSIENT_LOCAL data.

Note that the amount of TRANSIENT_LOCAL data retained by writers is  (like for TRANSIENT data ) driven by the topic-level durability_service settings

As non-volatile/durable data needs to be (resource-)controlled, the topic-level durability-service QoS-policies (kind/depth & resource-limits) are used to do that (for both TRANSIENT and TRANSIENT_LOCAL data behavior). If you KEEP_ALL samples then you may need to set max_samples/instances to ensure memory does not run out.