Chapter 17 — Isolate Communication and Collection Domains
Chapter objective: After this chapter, a developer can configure communication and collection domains separately and use equal entry keys to prove that the two identity layers remain distinct.
Learning objectives
- Distinguish
clusterId,serviceId, and collection locator. - Explain validation of cluster, service, and collection identity on a message.
- Prove that equal entry keys under different locators identify different state.
- Avoid treating a Spring bean name as wire identity.
Prerequisites
- Locator from Chapter 3 and
serviceIdfrom Chapter 10 are understood. - Spring bean registration from Chapter 16 is complete.
- Container identifiers and distributed-protocol identifiers are distinct.
Case progress
The gateway and worker both use entry key
fulfillment-primary in one Runtime, under
route-hints and shard-owners. A test
environment can also use the same locator while a different
cluster/service identity keeps its messages separate from
production.
Two boundaries, not interchangeable names
| Identifier | Scope | Purpose |
|---|---|---|
clusterId |
Runtime/sync envelope | membership in one deployment cluster |
serviceId |
membership and sync envelope | instances that discover and exchange DSM messages |
tenantId |
collection locator | state namespace or tenant ownership |
applicationId |
collection locator | application subdomain owning the collection |
collectionId |
collection locator | stable identity of one collection |
Spring bean-name |
one application context | code selecting a registered handle |
entryKey |
inside one collection | entity inside that collection |
An entryKey gains meaning with its complete locator.
Equal keys under different collection or application IDs do not identify
one business object.
A message crosses two identity checks
Membership rejects discovery/messages from a different
serviceId; RuntimePlatformSyncService also
validates clusterId and serviceId in the
envelope. After the communication domain accepts it, collection routing
resolves the locator and handle.
network reachability
→ clusterId/serviceId match
→ collection descriptor/locator match
→ schema/capability match
→ apply entryKey inside target collectionEvery rejection layer has an observable reason. Missing data cannot be attributed to locator without checking the earlier gates.
The
equal-key counterexample in RuntimeIntegrationTest
One Runtime registers shared/gateway/route-hints and
shared/worker/route-hints. Both Registers receive
same-key; one stores gateway-value, the other
worker-value. Each size remains one and each returns its
own value. Locator, rather than Java entity type or entry key alone,
owns collection identity.
Renaming distributed identity is protocol migration
Changing a bean alias affects one Spring context. Changing locator, cluster ID, or service ID changes distributed communication or state identity. It needs dual-write/migration, a compatibility window, or an explicit cold-start policy rather than an ordinary code rename.
Counterexample and fault injection
- Configure two collections with one locator and expect startup rejection.
- Give two Runtimes different service IDs and expect separate member views.
- Write the same key under different application IDs and expect isolated values.
- Change only the bean alias and confirm locator/wire identity remain unchanged.
Experiment
cd submodule/dsm
mvn -q -pl dsm-integration-test,dsm-cluster -am \
-Dtest=RuntimeIntegrationTest,MulticastClusterMembershipTest \
-Dsurefire.failIfNoSpecifiedTests=false testInspect isolation-cases.json; each scenario identifies a
change to communication domain, collection domain, or
application-context name.
Experiment acceptance card
| Field | Content |
|---|---|
| Command | The focused Runtime/membership tests above plus the book asset test |
| Input or fault | equal key, different locator, different service ID, and duplicate locator |
| Observable result | locator isolates values; service ID isolates membership; duplicate locator fails fast |
| Evidence level | E2 single-Runtime isolation plus E3 controlled multi-node membership |
| This experiment does not prove | Operating-system/network isolation, authorization, or tenant-data compliance |
Review
clusterId/serviceIdcontrols communication; locator controls collection state.- A bean name serves dependency injection and is not wire identity.
- Equal entity types and entry keys do not merge across locators.
- Distributed-identity changes need a migration plan.
Next
Chapter 18 arranges the preceding tests into an evidence ladder and states what each layer proves and leaves open.