[alexanderkurash]

Purpose

Prevent race conditions when concurrent operations recalculate positions in the same request queue.

Previously, simultaneous request creation or other queue-changing operations could read the same queue state and persist duplicate or inconsistent positions.

https://folio-org.atlassian.net/browse/CIRC-2697

Approach

• Introduced a database-backed request queue lock using the request-queue-lock-storage interface.
• Identified the effective queue by:
  • instance ID when TLR is enabled;
  • item ID when TLR is disabled.
• Limited the critical section to:
  1. acquiring the effective queue lock;
  2. retrieving a fresh lightweight queue;
  3. recalculating and persisting queue changes;
  4. releasing the lock.
• Applied locking to every flow that changes request positions:
  • request creation;
  • check-in and check-out;
  • cancellation and deletion;
  • moving requests between items;
  • manual queue reordering.
• Added configurable lock TTL, retry interval, maximum wait time, and feature enablement through mod-settings.
• Added retry with jitter for lock contention and a 503 Service Unavailable response when lock acquisition times out.
• Ensured locks are released after both successful and failed operations.
• Added unit and integration coverage, including concurrent item-level and title-level request creation.

This change requires the corresponding request-queue-lock-storage implementation from CIRCSTORE-684.

TODOS and Open Questions

• Check logging — lock acquisition, release, timeout, failure, wait time, and hold time are logged.
• Run the full test suite — 3,884 tests passed with no failures or errors.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
89.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[roman-barannyk]

static import?

[OleksandrVidinieiev]

Add method name to log message?