Design an "Internal Service State" facility

[jsync-swirlds]

Note

This Feature is on hold pending further design and discussion. It may be possible to completely avoid the need for local state storage, and we may realize significant improvements by doing so¹.

Goal

Design a facility for services to persistently store and retrieve data regarding internal service state.

Intention

The facility is intended to support values like the last block verified, or the oldest block persisted. This item is not actually needed¹.
This data is intended to be stored and accessed as simple key-value pairs, and to persist between application restarts.
The facility is intended to offer a simple interface to store and read values.
We intend to offer a message-based interface at some point, but might not implement that initially.

Considerations

• Why not store everything in the server status service
  • Each service, including third-party plugins, may need to determine independently what to store, when to store, and when to read data.
  • Server status may listen for data stores and reads to detect values it is interested in, but the services should manage their own values.
  • Having a general facility allows services better control without requiring changes to the Status Service to accommodate other services.
  • Mixing this function into server status needlessly complicates that service.
• Why not have each service manage its own data storage
  • Allowing (or encouraging) each service to store these small data values independently invites all manner of unexpected storage mechanisms and unnecessarily adds complexity to our own services.
  • Having this facility does not constrain service developers, but does offer a useful common functionality.

Technical Details

A direct call interface might include the following

• void storeValue(String keyName, String newValue) throws StoreFacilityException
• String getValue(String keyName)
• void removeValue(String keyName) throws StoreFacilityException

A message-based interface might include the following
Messages listened for

• StoreValue[String keyName, String newValue]
• RetrieveStoredValue[String keyName]
• RemoveStoredValue[String keyName]
  Messages emitted
• ValueRetrieved[String keyName, String retrievedValue]
• ValueRemoved[String keyName, String removedValue]
• ValueStored[String keyName, String StoredValue]
  Any entity (not just the requesting entity and facility) can listen for the store/stored or retrieve/retrieved pairs and update its own in-memory state to reflect things like last known block or price lists.

Footnotes

1. It turns out things like last verified block, earliest available block, and last available block are better determined by checking the filesystem in the persistence service (if it's installed). This keeps the mechanism and rules for determining what is actually available on startup and dynamically at runtime something controlled by the same service that manages the data. ↩ ↩²

[Nana-EC]

We may come back to this in the future but not a focus at this time.

[Nana-EC]

@jsync-swirlds based on the current updated architecture how might we adjust this?

[jsync-swirlds]

@jsync-swirlds based on the current updated architecture how might we adjust this?

I don't think we need to make any changes at this time.
It's not needed by anything we currently have, but we believe it will be needed for some items that come up with TSS and/or state management.

Once we have clear use cases, we will want to go through a more detailed pass to ensure we have a high-level design that will meet requirements.