◼ Apache Ignite Свойства продукта

Apache Ignite 2

Cache API, serializable transactions, cluster state и affinity

Публичные свойства продукта, восстановленные по тестовым свидетельствам.

Cache API, serializable transactions, cluster state и affinity

Эта страница — публичная реконструкция продуктовой спецификации по исходникам тестов Apache Ignite 2 на ревизии 486a6367610c4c891b729e89373695ef83165345.

Эти требования описывают совместимость базового Cache API, поведение serializable transactions при конфликтах, семантику activation/deactivation, cache groups и сходимость affinity при изменениях топологии и жизненного цикла cache.

Пользовательские гарантии

Трассируемые требования

После имени теста указывается только негативный или неоднозначный статус, например status=failed, status=flaky, status=ignored или status=mixed.

CACHE-API-VARIATIONS-01 — базовый Cache API согласованно работает в разных вариантах конфигурации cache

Требование: Для конфигураций Ignite cache, покрытых IgniteCacheConfigVariationsFullApiTest, user-visible cache operations должны сохранять JCache/Ignite API semantics across atomic/transactional variants, synchronous и async forms, transaction modes, local/global operations, skip-store views, expiry, locks, entry processors, iterators, и entry access APIs.

Зачем это нужно: приложения должны иметь возможность переключать cache mode, transaction mode и async/sync форму API без потери базовой семантики cache и без несовместимого edge-case behavior.

Граница: Это широкая compatibility-сетка, а не одно минимальное доказательство. Некоторые методы делегируют проверки в inherited helper suites, а часть entries требует просмотра helpers вместо прямых локальных assertion lines. Это не доказывает каждую пользовательскую cache configuration, persistence mode, topology timing или failure mode.

Тесты-доказательства:

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

Требование: Under the CacheSerializableTransactionsTest fixture, serializable optimistic transactions должны оставлять read-only transactions side-effect-free, make committed writes visible on server/client cache views, и discard rolled-back writes.

Зачем это нужно: Пользователи полагаются на serializable isolation чтобы make transaction outcome deterministic across partitioned/replicated, backup, store, и near-cache configurations.

Граница: Покрывает the fixture’s generated cache configurations и test key placement helpers; не доказывает arbitrary transaction workloads or non-optimistic serializable variants.

Тесты-доказательства:

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

Требование: If an optimistic serializable transaction reads a key or entry и another transaction changes that read key до commit, Ignite должен отвергать the stale transaction с TransactionOptimisticException и сохраняют the concurrent committed value; transactions whose read set является не invalidated may commit.

Зачем это нужно: Это the core serializable conflict contract: пользователям нужны stale decisions чтобы fail rather than silently overwrite concurrent committed data.

Граница: Conflicts являются deterministic helper scenarios over выбранные primary/backup/near keys. Тесты не доказывают starvation freedom or каждый operation interleaving.

Тесты-доказательства:

TX-SERIALIZABLE-03 — non-conflicting serializable updates и contains/read checks commit, включая partial-lock rollback cases

Требование: Optimistic serializable transactions должен commit updates когда their read set является не invalidated, возвращают in-transaction reads согласованный с the transaction’s own writes/removes, и roll back the full transaction if a required key является externally locked.

Зачем это нужно: Пользователям нужны serializable transactions чтобы быть strict about real conflicts без rejecting safe writes, и partial lock ошибка должен не leave partial data behind.

Граница: Does не доказывают fairness or timeout policy; lock-conflict cases являются controlled two-key helper scenarios.

Тесты-доказательства:

TX-SERIALIZABLE-04 — serializable transactions сохраняют near-cache, cross-cache, account-transfer, и restart/concurrency invariants

Требование: Serializable transactions должны сохранять committed values coherent across near caches, multiple caches in one transaction, repeated increments, get/remove races, account-transfer workloads, topology restarts, и mixed serializable/non-serializable concurrent updates без deadlock or invariant loss.

Зачем это нужно: Real deployments combine clients, near caches, multiple caches, restarts, и mixed transaction styles; serializable isolation является useful only if global invariants survive those operational shapes.

Граница: Several являются stress/timed scenarios и доказывают absence of observed violations, не exhaustive liveness. Publish only после reviewing each helper-backed workload.

Тесты-доказательства:

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

Требование: Transitioning a cluster between INACTIVE, ACTIVE, и ACTIVE_READ_ONLY из server or client nodes должен consistently раскрывают or hide configured caches on все joined nodes, включая repeated active-inactive-active cycles.

Зачем это нужно: Операторам нужны state changes чтобы быть cluster-wide и repeatable; приложения cannot tolerate split cache visibility после activation or deactivation.

Граница: Packet helper доказательства являются indirect; точные helper assertions должен быть reviewed до splitting into public spec clauses.

Тесты-доказательства:

CLUSTER-STATE-02 — joining и reconnecting nodes converge во время cluster-state transitions

Требование: Server/client nodes that join or reconnect при этом activation/deactivation является complete or in progress должен converge чтобы the final cluster state и корректный cache visibility после the transition completes.

Зачем это нужно: State transitions являются operational events; nodes joining во время them должен не require manual repair or наблюдают durable inconsistent state.

Граница: Timing является controlled by TestRecordingCommunicationSpi; this является deterministic race harness, не proof для все network partitions.

Тесты-доказательства:

CLUSTER-STATE-03 — state-change failover и MXBean deactivation сохраняют final state rules

Требование: Activation, deactivation, и read-only enable/disable должны завершаться чтобы a coherent final state despite node failures/restarts во время the transition, и JMX deactivation должен enforce data-loss warnings unless persistence or forced deactivation makes it safe.

Зачем это нужно: Операторам нужны state-change commands и management APIs чтобы быть reliable во время failover и conservative about in-memory data loss.

Граница: Failover patterns являются specific чтобы blocked transition messages и выбранные node indexes; JMX requirement includes точные diagnostic text.

Тесты-доказательства:

CACHE-GROUPS-01 — caches sharing a group остаются logically isolated при этом sharing group infrastructure

Требование: Caches в одной cache group должны сохранять per-cache data isolation, expiry policy behavior, iterators, scan queries, continuous query listeners, loadCache sources, и full cache API behavior across partitioned/replicated и atomic/transactional modes.

Зачем это нужно: Cache groups являются an operational/storage optimization; пользователи должен не see one cache’s data, query events, store loads, or API operations leak into another cache in the same group.

Граница: Some helper-backed API и query groups нужны representative review; listener timing uses bounded waits.

Тесты-доказательства:

CACHE-GROUPS-02 — cache group metadata, rebalance, и lifecycle остаются согласованный при joins, many caches, destroy, restart, и concurrency

Требование: Cache-group discovery metadata, per-cache ids, rebalance contents, partition iterators, key spaces, и lifecycle cleanup должен оставаться согласованный при этом caches являются started/destroyed, nodes join/restart, и concurrent operations continue.

Зачем это нужно: Операторы могут безопасно использовать grouped caches at scale only if metadata и partition ownership stay корректный через topology и lifecycle churn.

Граница: Stress/concurrency тесты являются time/iteration bounded и полагаются на absence of unexpected errors; точные внутренний cache-map assertions являются implementation-facing доказательства для a user-visible lifecycle consistency requirement.

Тесты-доказательства:

LATE-AFFINITY-01 — late affinity assignment converges чтобы expected ideal/public affinity после topology/cache changes

Требование: Ignite должен delay и then publish affinity assignments so public affinity APIs и внутренний ready versions converge после server/client joins/leaves, coordinator absence, cache create/destroy/recreate, и client cache start/close.

Зачем это нужно: Correct routing, partition ownership, и service placement depend on nodes agreeing about affinity после topology и cache lifecycle changes.

Граница: Many assertions live in affinity helpers и внутренний exchange futures; random stop и concurrent static-cache cases являются stress доказательства.

Тесты-доказательства:

LATE-AFFINITY-02 — blocked exchange-finish и delayed-assignment races не раскрывают premature or inconsistent affinity

Требование: When exchange-finish messages, supply messages, coordinator leave, custom affinity-change events, or unexpected PME timing являются blocked/released, Ignite должен не mark later affinity versions ready prematurely и должен converge чтобы identical partitions после the exchange completes.

Зачем это нужно: During topology churn, premature affinity readiness can route reads/writes/services чтобы the wrong owner or сообщать о a стабильный topology that является не actually стабильный.

Граница: Это a race harness с synthetic message blocking и bounded sleeps; absence из ошибка snapshot является не clean pass signal.

Тесты-доказательства:

Важные границы