Windows KTM/TxF: Can durable abort win against an outstanding commit within a fixed deadline?

Question

Windows KTM/TxF: Can durable abort win against an outstanding commit within a fixed deadline?

Kashif Kazi 20

I need clarification on a Windows transaction/durability guarantee for a fail-closed user-mode system.  

Environment:
- Windows
- User-mode application
- Native Win32/NT filesystem operations
- Considering KTM/TxF, ESE, or another supported Windows mechanism

Scenario: 
One logical transaction can end in exactly one authoritative state:

1. COMMITTED — a durable effect becomes authoritative
2. REVOKED — the transaction is irreversibly closed and the pending effect
   must never later become authoritative

The difficult case is when a durable commit is already outstanding when
revocation is requested.

For example:

    durable commit starts
        ↓
    commit is still pending
        ↓
    application deadline is reached
        ↓
    revocation/abort is requested

I need a durable ordering mechanism where exactly one side wins.

If REVOCATION wins, an already-running or stale actor must not later be able
to make its pending effect authoritative, even if that process or I/O request
continues running.

My requirement is NOT that all processes or I/O physically terminate within
the deadline.

The requirement is that the application can establish an irreversible,
crash-recoverable "revocation won" state within a 5-second closure reserve.

My question is:

Does Windows provide a supported mechanism — KTM/TxF, ESE, or another
facility — where a competing durable commit and revocation share one
authoritative ordering domain, and where revocation can be proven to have won
within a documented finite time bound without waiting indefinitely for the
outstanding commit to complete?

The two intended uses are:

- preventing a pending filesystem publication/rename from becoming
  authoritative after revocation;
- accepting exactly one durable terminal result, while rejecting stale results
  after revocation.

I am specifically trying to distinguish:

- abort/revocation requested;
- abort/revocation actually won;
- commit actually won;
- caller observed completion;
- durability established;
- crash-recovery outcome.

A timeout, process termination, or cancellation request alone is not sufficient
for my requirement.

If Windows provides durable ordering but intentionally provides NO documented
finite upper bound for commit/abort completion, confirmation of that would also
answer the question.

Pointers to the relevant Microsoft documentation would be appreciated.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello @Kashif Kazi ,

Thank you for the detailed write-up. I checked the Windows documentation against each part of your requirement, and I want to be direct about what the platform does and does not guarantee.

I would not recommend building this on KTM/TxF. Microsoft's Alternatives to using Transactional NTFS page states that TxF may not be available in future versions of Windows and strongly recommends investigating alternatives rather than adopting it.

Even setting deprecation aside, KTM does not give you what you are asking for. CommitTransaction can only be called while the transaction is still active, and the Timeout parameter of CreateTransaction only aborts the transaction if it has not already reached the prepared state. In other words, KTM does give you a single ordering domain with exactly one outcome, but once a commit has been issued and the transaction has passed the prepared point, there is no documented path for a later abort to override it. RollbackTransaction is documented only as synchronous, with no completion bound, and the KTM programming model explicitly tells you never to assume a transaction is active because it can be rolled back at any time.

ESE is a healthier choice for durability, but it has the same shape. JetCommitTransaction waits for the log flush by default, so the transaction is durable when the call returns, and any transaction committed with JET_bitCommitLazyFlush that was not flushed before a crash is automatically aborted during recovery in JetInit. However, ESE likewise cannot roll back a commit that has already been issued, and it does not document a time bound for commit completion.

So, to answer your closing question directly: Windows provides durable ordering with one outcome per transaction, but it does not document a finite upper bound for commit or abort completion in KTM/TxF or ESE, and it does not provide any mechanism where an abort is guaranteed to win over an already-issued durable commit.

What I would recommend instead is to own the ordering domain in your application and stop treating the in-flight commit as the thing that needs to be blocked. Make the authoritative fact a single durable terminal-state record that both sides must write atomically; whoever lands the record first wins, and the loser observes it and stands down. Concretely, I would keep one small file per logical transaction (for example txn\<id>.state), write it to a temp file, call FlushFileBuffers, and then publish it with MoveFileEx using MOVEFILE_REPLACE_EXISTING and MOVEFILE_WRITE_THROUGH, or with ReplaceFile. A same-volume NTFS rename is atomic, so exactly one writer creates the record. If you prefer ESE, a JetInsert on a unique key achieves the same thing because the second writer receives JET_errKeyDuplicate.

The important design rule is that the published payload is never the authority. Consumers only trust the published file when the record says COMMITTED, and any actor must read the record before publishing; if it says REVOKED the actor must not publish, and a rename that completes late is harmless because nothing treats it as authoritative. On crash recovery you scan the records: a present record is the truth, and an absent record means REVOKED, which keeps you fail-closed with no in-doubt state. This also gives you the six distinctions you listed. A request is the write attempt, revocation winning is the rename or insert succeeding, commit winning is finding the other side's record already present, caller observation is the API returning, durability is established after the write-through or the non-lazy ESE commit, and the crash-recovery outcome is simply the presence and content of the record.

On the 5-second reserve, I want to be honest: revocation under this design is one small write plus one rename, which completes in milliseconds in practice, but Windows does not document an upper bound for any disk I/O, including write-through. If the deadline is hard, I would enforce it at the application layer, for example by treating "not confirmed within the reserve" as REVOKED, which is consistent with your fail-closed requirement.

If you need a formal written guarantee beyond what the public documentation states, that would require a Microsoft Developer Support case, since I can only speak here to what is documented. You can open a professional support request through Microsoft Support for Business.

I hope this helps. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Kashif Kazi 20 Reputation points

2026-09-29T05:14:39.3933333+00:00

Thank you — this directly answers the main question I was trying to resolve.

My understanding from your answer is that KTM/TxF and ESE can provide durable transactional ordering, but Windows does not document a finite upper bound for commit/abort completion, and there is no documented mechanism that guarantees a later abort will override an already-issued durable commit. That clarification is very helpful.

I also appreciate the suggestion to move authority into an application-owned durable terminal-state record rather than trying to cancel the in-flight effect itself.

I have one follow-up on that design. If the terminal-state record itself is being durably written when the 5-second closure reserve expires, would it still be incorrect to treat “not confirmed within the reserve” as durably REVOKED, because that outstanding write could later complete?

In other words, would the safe interpretation still be:

confirmed COMMITTED record → COMMITTED

confirmed REVOKED record → REVOKED

neither outcome durably confirmed by the deadline → outcome remains UNKNOWN / fail-closed

rather than treating absence of a confirmed record at the deadline as proof that REVOKED has won?

I want to make sure I am not accidentally converting an observer timeout into an authoritative durable outcome.

Thank you again for the detailed answer and the documentation references.
Kashif Kazi 20 Reputation points

2026-09-29T10:28:01.9+00:00

Dear Taki Ly:
Thank you very much. This clarification is extremely helpful, especially the distinction that a timeout is only an observation and cannot itself establish a durable outcome.

I also appreciate you correcting the MOVEFILE_REPLACE_EXISTING point and clearly separating your local NTFS testing from documented Windows guarantees. That makes the boundary much clearer.

Your answer confirms the model I was trying to establish:

confirmed COMMITTED → COMMITTED

confirmed REVOKED → REVOKED

neither confirmed by the deadline → UNKNOWN / fail-closed

I am now looking at the next layer of the design: instead of requiring the outstanding physical operation itself to stop within the reserve, whether the application can make the authority to create any new authoritative state cease at the deadline, while allowing an already-running operation to finish only as non-authoritative evidence.

The difficult part I am examining is crash/restart safety — specifically, how to ensure that an old worker or late completion can never regain authority after restart without making the 5-second guarantee depend on another potentially unbounded durable disk write.

I may come back with one narrower question around that authority/fencing boundary once I have reduced it to a precise Windows semantics question.

Thank you again for taking the time to investigate this and for correcting the earlier detail.
Taki Ly (WICLOUD CORPORATION) 5,630 Reputation points Microsoft External Staff Moderator

2026-09-29T10:50:14.28+00:00

Hi @Kashif Kazi ,

Thank you for the follow-up, and I am glad the model is now settled on your side.

When you have reduced the authority and fencing boundary to a precise Windows semantics question, please post it as a new thread rather than continuing here. Keeping one issue per thread makes the question easier for others to find and reuse, and it lets the right people pick it up quickly. We will be happy to look into it once it is posted.

Thank you.