What Is Last-Write-Wins Concurrency?

Last-write-wins is a concurrency model in which, when two people save changes to the same record, the most recent save overwrites the earlier one with no conflict warning: there is no version check that stops the second writer or tells them the record changed underneath them. The plain analogy is a shared sticky note: two people edit the same note, and whoever saves last is the version that survives, with no alert to the one whose edits were replaced.

This entry is part of the EDGEBIC glossary; see the manufacturing glossary for the wider vocabulary and the scheduling policy definition for another site-wide behavior planners work within.

How Last-Write-Wins Works

When you open a record (a work center, a routing, an order) and save a change, the system writes your version to the database. The concurrency question is what happens if someone else opened the same record and saves too. Under last-write-wins, the answer is simple: whichever save lands second is the one that persists. The first save is not protected, and the second writer is not told anything changed.

There is no version marker being checked at save time. Some systems keep a hidden version number on each record and reject a save if the record changed since it was read, forcing the second writer to reconcile. That is optimistic concurrency, and it is the opposite behavior. Last-write-wins skips the check entirely, so both saves always succeed cleanly and the later one simply overwrites.

It is worth being precise about one detail: the plumbing for optimistic concurrency can exist in the data model (a version field on the record) while being switched off, so it is not enforced. When that is the case, the effective behavior is last-write-wins even though the version field is present. The field is there for a future in which conflict checks are turned on; today it is inert.

That inert-but-present arrangement is a deliberate design choice, not an oversight. Keeping the version field in place means conflict enforcement can be switched on later without a data migration, when the way a shop uses the system grows past a single planner. Until then, enforcing it would cost more than it saves: version checks that fire on stale reads can reject perfectly good saves and produce confusing prompts, which is worse than the rare silent overwrite for a shop that is not editing the same record from two seats. The model matches the current usage rather than a hypothetical one.

The Trade-Off

Every concurrency model trades one risk for another, and last-write-wins is a deliberate choice.

The benefit is clean, predictable saves. Nobody is ever blocked by a version conflict, nobody sees a confusing "this record changed, please reload" prompt mid-edit, and edits always go through. For a shop where one planner works one record at a time, that simplicity is exactly right and the downside never appears.

The cost is the silent overwrite. If two people do edit the same record at overlapping times, one person's changes vanish and neither is warned. The lost edits are not corrupted or half-applied; they are simply gone, replaced by the later save. That is why last-write-wins is a coordination consideration for multi-user setups: the safeguard is people agreeing who edits what, or refreshing before editing, rather than the system enforcing it.

A Concrete Example

Two planners open the same work center to adjust its settings. Planner A changes the number of machine instances and saves at 10:00. Planner B, who opened the record a minute earlier, changes the machine's color and saves at 10:01, working from the values as they were before A's save.

Under last-write-wins, B's save is the second one to land, so it overwrites the record with B's version, which still carries the old instance count. Planner A's instance change is gone, and neither planner is told. The record now shows B's color and the original instance count, as if A never edited it. The fix is not technical: A and B need to coordinate, or B needed to refresh before editing so their save carried A's change forward.

Had optimistic concurrency been enforced, B's save would have been rejected with a notice that the record changed, prompting B to reload and reapply. Last-write-wins trades that safety net for never interrupting a save.

How This Works in EDGEBIC

In EDGEBIC by User Solutions, the current concurrency model is last-write-wins. Records carry the field that a version check would use, but the check is not enforced, so concurrent saves resolve by whoever writes last. For a single planner, this is invisible: there is never a competing writer, so nothing is ever silently overwritten, and saves always behave exactly as expected.

For shops where more than one person edits master data at the same time, the practical guidance is coordination. Agree who owns which records during a shared session, and refresh a record before editing it so you are working from the latest values rather than a stale copy. That habit sidesteps the one situation where last-write-wins can cost you: two people, one record, overlapping edits.

The model is separate from anything the scheduling engine does; it governs how saved records resolve, not how the plan is built. For the standing rules that do shape scheduling behavior, see the scheduling policy and scheduling mode definitions, and for the broader planning vocabulary, what is production scheduling.

Last-write-wins is a straightforward, predictable model that fits single-planner and lightly-coordinated shops well. Know it is there, coordinate around shared records, and the one case it does not protect you from stays out of your way.