Atomic component writes do not extend across multi-component schema migrations in Dyalog APL 18.2

Question

ContextDyalog APL 18.2 component files support ⎕FPROPS 'Atomic' 1 and ⎕FPROPS 'Journaling' 1. The atomic property guarantees that a single ⎕FREPLACE or ⎕FAPPEND either fully succeeds or leaves that component unchanged. Journaling logs physical updates for crash recovery. Neither feature provides a transaction boundary across multiple components.ProblemA schema migration — replacing several components with arrays of different rank, shape, or type — requires multiple write operations. If the process terminates mid-migration (power loss, kill signal, unhandled error), the file can contain a mix of old-schema and new-schema components. The file system reports no corruption; ⎕FCHK validates physical structure only. There is no built-in rollback marker, no multi-component atomic commit, and no snapshot isolation to let readers see a consistent view.ConstraintsAtomic applies per component, not per logical transaction.No native BEGIN TRANSACTION/COMMIT/ROLLBACK API exists for component files.Concurrent access relies on ⎕FHOLD exclusive locks; no MVCC.Application-level patterns (shadow components, migration flags, versioned component numbers) are the only way to achieve all-or-nothing semantics.QuestionsIs there any documented or configurable behavior in Dyalog APL 18.2 that makes a multi-component schema change atomic without application-level coordination?When both journaling and atomic are enabled, does the journal contain enough information to reconstruct a consistent pre-migration state automatically, or must the application interpret it?Are there version-specific differences (32-bit vs 64-bit, V1/V2/V3 format) that affect the feasibility of a safe rollback strategy?

Tasadduq Burney · Answer

Direct AnswerThere is no documented or configurable behavior in Dyalog APL 18.2 that makes a multi-component schema change atomic. The ⎕FPROPS 'Atomic' 1 property applies only to individual component operations, not to logical transactions spanning multiple components. This is a deliberate design limitation, not an oversight.Confirmed Behavior vs. Likely ExplanationConfirmed: Dyalog APL 18.2 component files provide:Per-component atomicity for single ⎕FREPLACE or ⎕FAPPEND operationsJournaling of physical byte-level changes for crash recoveryExclusive locking via ⎕FHOLD for serialization⎕FCHK validation of physical structure onlyApplication-level patterns are required for:All-or-nothing semantics across multiple componentsLogical consistency between old and new schema versionsAutomatic rollback on failureJournal Content and InterpretationWhen both journaling and atomic are enabled, the journal contains low-level physical update records (byte offsets, data blocks). It does not contain logical transaction boundaries or pre-migration snapshots. Reconstructing a consistent state requires application interpretation of the journal to identify affected components and their pre-change values. The journal enables crash recovery but not automatic rollback.Version-Specific Considerations32-bit vs 64-bit and V1/V2/V3 format differences affect storage layout and addressing, but do not provide additional rollback mechanisms. The atomicity boundary remains per-component regardless of format version. Safe rollback strategies must be implemented at the application layer using:Shadow components: Write new schema to a separate component namespace, then atomically renameMigration flags: Use a control component to track migration state before committing changesVersioned component numbers: Encode schema version in component identifiers to allow readers to validate compatibilityVerification StepsTo confirm behavior in your environment:Create a test file with multiple componentsEnable both ⎕FPROPS 'Atomic' 1 and ⎕FPROPS 'Journaling' 1Begin a multi-component migrationTerminate the process mid-migration (e.g., kill signal)Run ⎕FCHK to verify physical integrityInspect individual components to observe mixed schema statesOne diagnostic detail needed: Are you experiencing a specific migration failure scenario, or is this a design question for implementing a new migration pattern?

Atomic component writes do not extend across multi-component schema migrations in Dyalog APL 18.2

Context

Problem

Constraints

Questions

1 answer

Direct Answer

Confirmed Behavior vs. Likely Explanation

Journal Content and Interpretation

Verification Steps

Your perspective belongs here.

1 question comment