This tutorial illustrates how to maintain a reference to a single provider while reloading the dataset from a memory location.
Code and Explanation
Reload from memory example that shows how to:
Use the provider structure to access the dataset as well as device
Use the fiftyoneDegreesProviderReloadFromMemory function to reload the
dataset, from the data file that has been read into a continuous memory
Run detections on the current User-Agent.
Use the reload functionality in a single threaded environment.
Use the reload functionality in a multi threaded environment.
This example demonstrates how to use the 51Degrees provider structure to
access the dataset as well as to invoke the reload functionality.
static fiftyoneDegreesProvider *provider;
Example assumes that the initial dataset was created using
either the fiftyoneDegreesInitProviderWithPropertyString function,
or the fiftyoneDegreesInitProviderWithPropertyArray function.
The fiftyoneDegreesProviderReloadFromMemory function requires an existing
provider structure with initialized dataset. Function reloads the dataset
from the provided pointer to the continuous memory space containing the data
file. New dataset is created with the same parameters as the original dataset.
: unlike the reload from file example you need to decide if
the 51Degrees API should dispose of the allocated file when the resources
are deallocated or if you wish to retain the allocated memory for later
use. To instruct the API to free the continuous memory space set the
memoryToFree pointer equal to the pointer of the file in memory.
Please keep in mind that even if the current dataset was constructed with
all available properties this does not guarantee that the new dataset will
be initialized with the same set of properties. If the new data file
contains properties that were not part of the original data file, the new
extra property(ies) will not be initialized. If the new data file does not
contain one or more property that were previously available, then these
property(ies) will not be initialized.
Each successful data file reload should be accompanied by the integrity
check to verify that the properties you want have indeed been loaded. This
can be achieved by simply comparing the number of properties before and
after the reload as the number can not go up but it can go down.
The reload functionality works both with the single threaded as well as the
multi threaded modes. To try the reload functionality in single threaded
mode build with FIFTYONEDEGREES_NO_THREADING defined. Or build without
FIFTYONEDEGREES_NO_THREADING for multi threaded example.
In a single threaded environment the reload function is executed as part of
the normal flow of the program execution and will prevent any other actions
until the reload is complete. The reload itself takes less than half a
second even for Enterprise dataset. For more information see:
This, and any other Trie example can be built to stream from file to reduce
memory overhead by defining FIFTYONEDEGREES_INDIRECT at compile time. This
encurs a performance penalty due to disk read and cache locking. Currently
the caching used for an indirect (file stream) data set does not reserve an
entity it has given out, so care should be taken to ensure an entity is not
removed from the cache while another thread is using it. This can be done by
defining FIFTYONEDEGREES_NO_THREADING and using the provider in a single
threaded environment. Alternatively, for a multi threaded environment, the
stream caches should be set to a higher number of entries than you expect to
be handed out to threads at any one time. This is done by defining:
In this tutorial you have seen how to maintain a single reference to the provider while reloading the dataset. This can be used to keep the data file up to date without downtime. For more information on data file release frequency, see