🎁 Get the FREE AI Skills Starter GuideSubscribe →
BytesAgainBytesAgain
🦀 ClawHub

Offline Concurrency Strategy Selector

by @quochungto

Use when designing concurrency control for long-running edits where a business transaction spans multiple system transactions — user opens a record, edits fo...

Versionv1.0.0
When to Use
TriggerAction
Use this skill when designing new editing workflows, diagnosing "lost update" bugs, or auditing existing lock strategies. It selects among four patterns from Fowler's *Patterns of Enterprise Application Architecture* Ch 16 and routes to child implementation skills when needed.
**Do not use** if the entire user workflow fits in a single request/transaction — standard database isolation levels are sufficient and far simpler.
💡 Examples

Example 1: CMS Article Editor (low collision, low rework cost)

Scenario: A content management system where editors write articles. Typical edit session: 10–30 minutes. Team of 5 editors; each article usually has one assigned editor. Collisions rare but possible.

Trigger: "We sometimes lose edits when two people accidentally open the same draft. Should we add locking?"

Process:

  • Step 1: Multi-request workflow (open draft → write → publish) → offline concurrency applies.
  • Step 2: Collision frequency = rare; rework cost = moderate (losing 20 min is painful but recoverable) → Optimistic Offline Lock.
  • Step 3: N/A (Pessimistic not chosen).
  • Step 4: Article is a standalone entity; no aggregate integrity concern → no Coarse-Grained Lock.
  • Step 5: Single article mapper; small team → Implicit Lock in abstract mapper for safety.
  • Step 6: No anti-patterns identified if schema is new.
  • Output: Add version INTEGER NOT NULL DEFAULT 0 + modified_by + modified_at to articles table. Abstract article mapper includes version in UPDATE WHERE clause. On row count 0 → show "This article was modified by [user] at [time]. Please copy your changes, reload, and re-apply." No lock table needed.


    Example 2: Insurance Policy Underwriting (high rework cost)

    Scenario: Underwriters edit complex insurance policies. Editing a policy takes 45–90 minutes (data gathering, actuarial calculations, document review). Two underwriters might be assigned the same policy. If an underwriter finishes after 90 minutes and their save is rejected, the work is genuinely lost — not a minor inconvenience.

    Trigger: "Underwriters are furious about rejected saves. Is there a better approach?"

    Process:

  • Step 1: Multi-request, 45-90 min sessions → offline concurrency applies.
  • Step 2: Collision rate: low (same policy rarely assigned twice) BUT rework cost: very high → Pessimistic Offline Lock.
  • Step 3: Underwriters need latest data (coverage amounts, actuarial tables) → Exclusive read lock (other underwriters cannot even load the policy while one holds it).
  • Step 4: Policy includes Coverages, Endorsements, Named Insureds → these form an aggregate → Coarse-Grained Lock with shared version on the Policy root.
  • Step 5: Multiple command objects (EditBasicInfo, AddCoverage, RemoveEndorsement) → Implicit Lock via LockingMapper decorator.
  • Step 6: Flag if existing code uses SELECT FOR UPDATE on policy table.
  • Output: Database lock table + shared version on Policy aggregate + LockingMapper + HTTP session expiration listener. UX: "Policy 12345 is currently being edited by Bob Smith. It will be available after his session ends or at [timeout time]."


    Example 3: E-commerce Order Management (aggregate integrity)

    Scenario: Customer service agents edit orders. An order has LineItems, ShippingAddress, and PromoCodes. One agent might add a LineItem while another changes the ShippingAddress at the same time. Each object in isolation is low-risk, but the order must be consistent as a whole.

    Trigger: "We have a bug where the order total is wrong — looks like two people edited it at the same time."

    Process:

  • Step 1: Multi-request order editing → offline concurrency applies.
  • Step 2: Collision frequency: occasional (busy customer service team); rework cost: low → Optimistic Offline Lock.
  • Step 3: N/A.
  • Step 4: Order + LineItems + ShippingAddress + PromoCodes = one aggregate → Coarse-Grained Lock with shared version on Order root. Any change to any member increments the shared version, blocking any concurrent session's commit.
  • Step 5: Order service has multiple command handlers → Implicit Lock in abstract repository.
  • Step 6: Verify no per-entity version columns (would create inconsistent locking if mixed with shared version).
  • Output: Single version table row per order, referenced by all members. Abstract mapper update() calls order.getVersion().increment() before any member update. Conflict error: "Order 8834 was modified by [user] at [time]. Please reload to see current state."

    View on ClawHub
    TERMINAL
    clawhub install bookforge-offline-concurrency-strategy-selector

    🧪 Use this skill with your agent

    Most visitors already have an agent. Pick your environment, install or copy the workflow, then run the smoke-test prompt above.

    🔍 Can't find the right skill?

    Search 60,000+ AI agent skills — free, no login needed.

    Search Skills →