Skip to main content

Concurrency

Audience​

Developers, database engineers, QA engineers, support engineers, security engineers, solution architects, and implementation partners.

Reference Content​

This page records source-verified Workforce Scheduling persistence behavior and boundaries.

Summary​

No row-version, concurrency token, compare-and-swap condition, or explicit isolation-level configuration was found for scheduling entities.

Database duplicate protection​

Unique constraints protect compatibility identity, tenant/weekday canonical rules, one default policy per tenant, and rule key within a policy.

Application-only protection​

Shift and policy name checks query before write. Assignment overlap checks load active rows before insert. These read-before-write checks can race between concurrent requests. Policy name also lacks a database uniqueness constraint.

Update conflicts​

Updates do not include an expected version. Last successful write can overwrite earlier values. Soft-deactivation checks active assignments before saving, which can race with assignment creation.

Classification​

Database uniqueness is Partial. Optimistic concurrency and temporal overlap enforcement are Not implemented. A concurrency strategy requires confirmation.

Source References​

  • microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
  • microservices/src/attendance-service/Application/Services/ShiftPolicyCommands.cs
  • microservices/src/attendance-service/Domain/TimeOffice/EmployeeShiftAssignment.cs

See Also​

Keywords​

  • Workforce Scheduling database
  • Shift persistence
  • Attendance policy storage

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Next review: 2026-10-20