Chapter 10. Asynchronous connection manager


General notes about managed objects and subscriptions
stasher::manager->manage_subscription(): a managed subscription
stasher::manager->manage_object(): automatically retrieve an object any time it changes
stasher::manager->manage_hierarchymonitor(): maintaining an internal snapshot of an object hierarchy
stasher::manager->manage_serverstatusupdates(): maintaining server status updates


As mentioned in the section called “stasher::client->subscribe(): object subscriptions”, if the connection to the server drops for any reason, the subscription to a hierarchy or an object gets cancelled. Although a new client connection thread gets started by the next request from the application, and it tries to reconnect to the server, the subscription does not get reopened automatically.

A manager object implements enhanced object and hierarchy subscriptions, then sets a timer when they get cancelled (one minute, by default). After the timer expires, the manager tries to reestablish the subscription (which makes another connection attempt to the server, if necessary).

stasher::manager manager=stasher::manager::create();

This creates a stasher::manager, an x::ref. The retry interval gets set by the property objrepo::manager, with the default value of one minute.

The entire application can use a single manager object, or different manager objects, there is no particular advantage, except that each manager instance can use a different timeout interval.

stasher::manager manager=stasher::manager::create(L"retry", "10 seconds");

This example creates a manager that uses the objrepo::manager property, with a ten second default value. The first parameter is the property name, as a wide string. The second parameter is an x::hms, which can be initialized from a literal string.

General notes about managed objects and subscriptions

  • A manager can manage objects and subscriptions from the same or different client connections.

  • If a manager object goes out of scope and gets destroyed, all managed objects and subscriptions no longer get managed. They're all LIBCXX's reference counted objects, and as long as a strong reference to them remains in scope, somewhere, they'll still exist, but won't be of much use. It's expected that a manager object will live nearby everything that it manages.

  • It doesn't matter whether the manager or its managed object goes out of scope and get destroyed first. Note, though, that managed objects maintain a strong reference to their client connection object, as a necessity, so they must go out of scope and get destroyed before the application's client connection handle.