The logical mapper could cache the current device mappings in memory as they are read from the database.
A database notification could be used as a signal to flush the cache when the mapping table is updated.
The logical mapper has an idle loop that sleeps for 2 seconds at a time while waiting for RabbitMQ messages or a signal to shut down so that can be used to poll the DB signal. The DB can include the physical device id in the notification so the logical mapper only discards the entry for that device.
There is a race condition where a message is delivered slightly out of sync with the DB notification but with the low message volumes we experience it probably isn't much to worry about.
However, if we're issuing a query every few seconds looking for DB notifications, that may be more load on the DB than what we have now with the low volume of traffic.
Special consideration must be made for older messages if issue #7 is implemented.
The logical mapper could cache the current device mappings in memory as they are read from the database.
A database notification could be used as a signal to flush the cache when the mapping table is updated.
The logical mapper has an idle loop that sleeps for 2 seconds at a time while waiting for RabbitMQ messages or a signal to shut down so that can be used to poll the DB signal. The DB can include the physical device id in the notification so the logical mapper only discards the entry for that device.
There is a race condition where a message is delivered slightly out of sync with the DB notification but with the low message volumes we experience it probably isn't much to worry about.
However, if we're issuing a query every few seconds looking for DB notifications, that may be more load on the DB than what we have now with the low volume of traffic.
Special consideration must be made for older messages if issue #7 is implemented.