◼ Apache Ignite Product Properties

Apache Ignite 2

Cache API, serializable transactions, cluster state and affinity

Public product properties reconstructed from test evidence.

Cache API, serializable transactions, cluster state and affinity

This page is a public product-spec reconstruction from Apache Ignite 2 test sources at revision 486a6367610c4c891b729e89373695ef83165345.

These requirements cover core cache API compatibility, serializable transaction conflict behavior, activation/deactivation semantics, cache groups, and affinity convergence under topology/cache lifecycle changes.

User-facing guarantees

Traceable requirements

Only negative or ambiguous test status is annotated after a test name, for example status=failed, status=flaky, status=ignored, or status=mixed.

CACHE-API-VARIATIONS-01 — cache core API behaves consistently across configured cache variants

Requirement: For Ignite cache configurations covered by IgniteCacheConfigVariationsFullApiTest, user-visible cache operations must preserve JCache/Ignite API semantics across atomic/transactional variants, synchronous and async forms, transaction modes, local/global operations, skip-store views, expiry, locks, entry processors, iterators, and entry access APIs.

Why: Applications should be able to switch cache mode, transaction mode, and async/sync API form without losing core cache semantics or getting incompatible edge-case behavior.

Boundary: This is a wide compatibility net, not a single minimal proof. Some methods delegate into inherited helper suites, and some entries require helper inspection rather than having direct local assertion lines. It does not prove every user cache configuration, persistence mode, topology timing, or failure mode.

Evidence tests:

TX-SERIALIZABLE-01 — read-only and read-write serializable optimistic transactions commit/rollback with visible all-node state

Requirement: Under the CacheSerializableTransactionsTest fixture, serializable optimistic transactions must leave read-only transactions side-effect-free, make committed writes visible on server/client cache views, and discard rolled-back writes.

Why: Users rely on serializable isolation to make transaction outcome deterministic across partitioned/replicated, backup, store, and near-cache configurations.

Boundary: Covers the fixture’s generated cache configurations and test key placement helpers; does not prove arbitrary transaction workloads or non-optimistic serializable variants.

Evidence tests:

TX-SERIALIZABLE-02 — concurrent writes that invalidate serializable reads cause optimistic transaction rollback

Requirement: If an optimistic serializable transaction reads a key or entry and another transaction changes that read key before commit, Ignite must reject the stale transaction with TransactionOptimisticException and preserve the concurrent committed value; transactions whose read set is not invalidated may commit.

Why: This is the core serializable conflict contract: users need stale decisions to fail rather than silently overwrite concurrent committed data.

Boundary: Conflicts are deterministic helper scenarios over selected primary/backup/near keys. The tests do not prove starvation freedom or every operation interleaving.

Evidence tests:

TX-SERIALIZABLE-03 — non-conflicting serializable updates and contains/read checks commit, including partial-lock rollback cases

Requirement: Optimistic serializable transactions must commit updates when their read set is not invalidated, return in-transaction reads consistent with the transaction’s own writes/removes, and roll back the full transaction if a required key is externally locked.

Why: Users need serializable transactions to be strict about real conflicts without rejecting safe writes, and partial lock failure must not leave partial data behind.

Boundary: Does not prove fairness or timeout policy; lock-conflict cases are controlled two-key helper scenarios.

Evidence tests:

TX-SERIALIZABLE-04 — serializable transactions preserve near-cache, cross-cache, account-transfer, and restart/concurrency invariants

Requirement: Serializable transactions must keep committed values coherent across near caches, multiple caches in one transaction, repeated increments, get/remove races, account-transfer workloads, topology restarts, and mixed serializable/non-serializable concurrent updates without deadlock or invariant loss.

Why: Real deployments combine clients, near caches, multiple caches, restarts, and mixed transaction styles; serializable isolation is useful only if global invariants survive those operational shapes.

Boundary: Several are stress/timed scenarios and prove absence of observed violations, not exhaustive liveness. Publish only after reviewing each helper-backed workload.

Evidence tests:

CLUSTER-STATE-01 — cluster activation/deactivation propagates cache availability across servers and clients

Requirement: Transitioning a cluster between INACTIVE, ACTIVE, and ACTIVE_READ_ONLY from server or client nodes must consistently expose or hide configured caches on all joined nodes, including repeated active-inactive-active cycles.

Why: Operators need state changes to be cluster-wide and repeatable; applications cannot tolerate split cache visibility after activation or deactivation.

Boundary: Packet helper evidence is indirect; exact helper assertions should be reviewed before splitting into public spec clauses.

Evidence tests:

CLUSTER-STATE-02 — joining and reconnecting nodes converge during cluster-state transitions

Requirement: Server/client nodes that join or reconnect while activation/deactivation is complete or in progress must converge to the final cluster state and correct cache visibility after the transition completes.

Why: State transitions are operational events; nodes joining during them should not require manual repair or observe durable inconsistent state.

Boundary: Timing is controlled by TestRecordingCommunicationSpi; this is a deterministic race harness, not a proof for all network partitions.

Evidence tests:

CLUSTER-STATE-03 — state-change failover and MXBean deactivation preserve final state rules

Requirement: Activation, deactivation, and read-only enable/disable must complete to a coherent final state despite node failures/restarts during the transition, and JMX deactivation must enforce data-loss warnings unless persistence or forced deactivation makes it safe.

Why: Operators need state-change commands and management APIs to be reliable during failover and conservative about in-memory data loss.

Boundary: Failover patterns are specific to blocked transition messages and selected node indexes; JMX requirement includes exact diagnostic text.

Evidence tests:

CACHE-GROUPS-01 — caches sharing a group remain logically isolated while sharing group infrastructure

Requirement: Caches in the same cache group must preserve per-cache data isolation, expiry policy behavior, iterators, scan queries, continuous query listeners, loadCache sources, and full cache API behavior across partitioned/replicated and atomic/transactional modes.

Why: Cache groups are an operational/storage optimization; users must not see one cache’s data, query events, store loads, or API operations leak into another cache in the same group.

Boundary: Some helper-backed API and query groups need representative review; listener timing uses bounded waits.

Evidence tests:

CACHE-GROUPS-02 — cache group metadata, rebalance, and lifecycle remain consistent under joins, many caches, destroy, restart, and concurrency

Requirement: Cache-group discovery metadata, per-cache ids, rebalance contents, partition iterators, key spaces, and lifecycle cleanup must remain consistent while caches are started/destroyed, nodes join/restart, and concurrent operations continue.

Why: Operators can safely use grouped caches at scale only if metadata and partition ownership stay correct through topology and lifecycle churn.

Boundary: Stress/concurrency tests are time/iteration bounded and rely on absence of unexpected errors; exact internal cache-map assertions are implementation-facing evidence for a user-visible lifecycle consistency requirement.

Evidence tests:

LATE-AFFINITY-01 — late affinity assignment converges to expected ideal/public affinity after topology/cache changes

Requirement: Ignite must delay and then publish affinity assignments so public affinity APIs and internal ready versions converge after server/client joins/leaves, coordinator absence, cache create/destroy/recreate, and client cache start/close.

Why: Correct routing, partition ownership, and service placement depend on nodes agreeing about affinity after topology and cache lifecycle changes.

Boundary: Many assertions live in affinity helpers and internal exchange futures; random stop and concurrent static-cache cases are stress evidence.

Evidence tests:

LATE-AFFINITY-02 — blocked exchange-finish and delayed-assignment races do not expose premature or inconsistent affinity

Requirement: When exchange-finish messages, supply messages, coordinator leave, custom affinity-change events, or unexpected PME timing are blocked/released, Ignite must not mark later affinity versions ready prematurely and must converge to identical partitions after the exchange completes.

Why: During topology churn, premature affinity readiness can route reads/writes/services to the wrong owner or report a stable topology that is not actually stable.

Boundary: This is a race harness with synthetic message blocking and bounded sleeps; absence from failure snapshot is not a clean pass signal.

Evidence tests:

Important boundaries