Credential Rotation Without Race Conditions: Short Transactions and lockForUpdate()

Credential rotation looks simple: invalidate the current secret, create a new one, and persist it.

The interesting problem appears when two requests try to do this at almost the same time.

Both may read the same current state. Both may decide that the active credential is still eligible for replacement. But only one of them should win.

I encountered exactly this case in the ProductRegistry module of AVN Center while implementing Product Registration credential rotation.

The solution combines several pieces: a short transaction, an authoritative re-read under lockForUpdate(), and an atomic replacement of the old credential with the new one.

At the beginning of the use case, RotateProductRegistrationCredential loads the current credential and verifies that it matches the authenticated context.

The checks cover:

• Product Registration identity;
• credential environment;
• authentication profile.

This validation is necessary, but it happens before the database write.

Between that read and persistence, another request may already complete a rotation. The earlier object therefore cannot be treated as authoritative at write time.

The next important detail is that the new secret and its hash are prepared before the database transaction begins.

Generating the secret does not require a database row lock. Neither does hashing it.

Doing that work after lockForUpdate() would keep the authoritative row locked longer than necessary.

The Application use case therefore prepares everything that does not depend on the database first, and only then enters the atomic replacement operation.

When persistence begins, the repository does not trust the state that was read earlier.

replaceActiveCredential() opens a transaction, finds the current record by its identifier, and reads it using lockForUpdate().

This provides two important properties:

• while the transaction owns that row lock, another competing change cannot complete an incompatible write against the same state;
• the decision is based on state confirmed by the database at write time rather than an older in-memory snapshot.

Checking only status = active is not enough.

The persisted record must still belong to the same security binding that was authenticated earlier.

Under the lock, persistence therefore verifies:

• registration_id;
• environment;
• authentication_profile.

If any part no longer matches, rotation fails with a write conflict instead of writing new material over state that has already changed.

After the authoritative checks succeed, the current active credential becomes superseded and the replacement is inserted as active.

Both writes happen inside the same transaction.

This avoids two unwanted intermediate states:

• the old credential is already inactive but no replacement exists;
• the replacement exists while the old credential is still active.

For this operation, there is only one valid outcome: the old credential is completely replaced by the new one, or the entire operation rolls back.

This is where the limitation of the initial Application check becomes clear.

Both requests may legitimately observe active before either write begins.

But after the first transaction commits, the second request acquires the lock on an already changed record. Its authoritative re-check sees that the credential is no longer active and stops the second rotation.

The goal is not to prevent a concurrent request from existing. The goal is to ensure that only one competing write can become authoritative.

The row lock and authoritative re-check do not replace database constraints.

For one Product Registration, environment, and authentication profile, the system must not have more than one active credential.

Database uniqueness therefore remains the final guard. If persistence still violates that rule, the database error is converted into a controlled ProductRegistrationCredentialWriteConflict.

For concurrent code, I want both layers: an explicit check in the code and a hard guarantee where the authoritative state is physically stored.

In this case, the transaction protects one very specific critical section:

• lock the current row;
• re-check its authoritative state;
• mark the old credential as replaced;
• insert the replacement;
• commit the result.

Secret generation and hashing stay outside because they do not need protection from the database row lock.

The less work performed between lockForUpdate() and commit, the less time the critical row remains locked.

This case shows the difference between ordinary validation and actual protection against concurrent writes.

An early check is useful for fast failure, but it cannot guarantee that the state remains unchanged until persistence.

At the critical point, I therefore return to the source of truth: the database re-reads the row under a lock and only then permits the state transition.

The atomic replacement guarantees that the old credential does not become inactive without a replacement and that the replacement does not appear beside an old credential that is still active.

In concurrent flows, I do not only want to validate state. I want to validate it again at the exact place where that state is about to change.