Transaction locks

MVS allows multiple users to view and edit schedule data, and multiple users can make edits to the same shift simultaneously. Shifts are locked using a transaction lock when a user performs a transaction on the shift. This prevents the shift from entering an invalid state because of transactions performed simultaneously by other users.

A transaction lock is placed on a shift when a transaction is initiated, and the shift is unlocked when the transaction is completed. Transactions performed on the same shift by other users during the locking or unlocking process may be canceled or held until the locking or unlocking process is completed. Duplicate transactions performed on the shift during the locking or unlocking process are canceled with a transaction lock error. New transactions performed on the shift can also be canceled if they cannot pass the regular shift validations due to changes performed in the original transaction.

Note: The locking and unlocking process occurs directly in the database and is typically completed in a matter of milliseconds. Users are not notified if a transaction is held, because the hold time is so short. A message is displayed to users if their transaction has been canceled by a transaction lock error or if their transaction fails regular shift validations. Transaction locks are not displayed in the scheduling screens.

Transactions on a shift are performed in the order of when they are received by the system, with the earliest transactions being executed first. Network latency can affect which transactions are received first.

Transaction locks may not be removed from shifts in rare cases, such as when an exception occurs during a transaction. The Unlock Shift Task removes transaction locks that are older than the specified time-out time. This allows users to edit locked shifts again.

See Unlock Shift Task.

Transaction lock examples

This section describes examples where two transactions are performed by multiple users on the same shift. This section describes the behavior of the transaction lock and the expected result of the transactions for each example.

It is important to note that the transactions described in these examples are performed nearly simultaneously. These transactions are often completed within a short span of time, such as within milliseconds. The actual outcomes of these examples may change due to network latency or the timing of when the system recognizes and processes transactions.

Example 1: Duplicate book off transactions

When duplicate transactions are performed on the same shift, the first transaction is completed, and the second transaction is canceled. In this example, an employee sends an email to notify their two supervisors that they are sick and cannot work their shift. Supervisor A and supervisor B both book off the employee’s shift, with supervisor A’s transaction being received by the system first. This sequence of events takes place:

  1. Supervisor A books off the shift.
  2. Shift is locked for supervisor A’s transaction.
  3. Supervisor B books off the shift.
  4. The shift is booked off.
  5. The transaction lock is removed from the shift.
  6. Supervisor B’s transaction is canceled as the shift is already booked off.

Example 2: Conflicting transactions

The second transaction is canceled if the first transaction causes the shift to be in a state that makes it impossible to perform the second transaction. In this example, a scheduler unassigns a shift from an employee. The supervisor simultaneously books off the same shift. The scheduler’s unassign transaction is received by the system first. This sequence of events takes place:

  1. The scheduler unassigns the shift.
  2. The shift is locked for the scheduler’s transaction.
  3. The supervisor books off the shift.
  4. The supervisor’s edits are held.
  5. The shift is unassigned.
  6. The transaction lock is removed from the shift.
  7. The supervisor’s book off transaction fails shift validation, as the shift is now unassigned so cannot be booked off.