Caching Strategy (Hazelcast)
Role of Hazelcast in the platform
Hazelcast is a required, shared cluster used by multiple backend services.
ft-configs-service publishes derived, read-optimized configuration snapshots into Hazelcast so other services can read them at runtime without reading files or querying the configs database.
-
Database is the source of truth.
-
Hazelcast contains snapshots/read models.
-
Consumers include
ACS,northbound-api,provisionportal,serviceapi, and an “angular backend” that read Hazelcast directly.
Hazelcast Client Configuration
Hazelcast wiring is provided by dependency com.friendly:ft-cache:0.0.8:
-
Default client YAML resource:
hazelcast-client.yamlon the application classpath (packaged insideft-cache). -
Config file location property:
cache-config.path(defaultclasspath:). Effective resource is${cache-config.path}hazelcast-client.yaml. -
Member override env var:
HZ_MEMBERS(comma/space separated); when set, it overrideshazelcast-client.network.cluster-members. -
Embedded member mode (not used for this service in production):
cache.is-server=truemakes it load${cache-config.path}hazelcast.yamland start a Hazelcast member.
Known production setting (confirmed): hazelcast-client.cluster-name=dev.
Cache Catalog (maps/lists)
| Cache | Type | Key → Value (publisher) |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
index → |
| The table uses short publisher class names to keep the rendered layout stable. See the service packages in code for fully qualified names. |
Consistency and Refresh Semantics
What is implemented
-
Most cache services warm up on startup (
@PostConstruct), by reading DB and writing to Hazelcast. -
Many domain services call cache refresh methods after writes to keep Hazelcast close to DB state (for example
NetworkMapServicecallsNetworkMapCacheService.refreshClientType).
Known correctness requirements and gaps
The intended contract (confirmed) is:
-
Hazelcast snapshots must be updated only after the database transaction commits.
Current code has gaps:
-
Many refresh calls execute inside the same
@Transactionalmethod and may publish before commit. -
tabscache is warmed on startup (TabCacheService.init()), but is not refreshed by/tabs/**write/import flows today (this is a known bug:TabServiceandTabImportServicedo not invokeTabCacheService).
