Why do we need concurrency control?

To prevent lost updates and dirty reads when multiple jobs or users access the same data.

What is record locking?

A mechanism to prevent others from changing a record while it is being read/updated.

COBOL Concurrency Control

Q: Optimistic vs pessimistic?

Optimistic assumes no conflict and checks at commit; pessimistic locks up-front.

When multiple jobs or users access the same data, you must prevent conflicts. Choose an approach based on file type (VSAM/DB), environment (batch/CICS), and contention risk. This covers locking strategies, isolation levels, and conflict resolution.

Record Locking (Conceptual)

cobol

1
2
3
4
5
6
7
8
9
10
       *> Pseudocode: lock then read-update-write
       IF NOT LOCK-OBTAINED
           PERFORM RETRY-BACKOFF
       ELSE
           READ CUSTOMER-FILE
           COMPUTE NEW-BALANCE = CURRENT-BALANCE + TRANSACTION-AMOUNT
           MOVE NEW-BALANCE TO CURRENT-BALANCE
           REWRITE CUSTOMER-RECORD
           RELEASE-LOCK
       END-IF.

Host environments provide the primitives (e.g., VSAM shareoptions, RLS, DB locks). Your program must handle retries and backoff. Always release locks promptly to avoid deadlocks.

Detect and Resolve Conflicts

cobol

1
2
3
4
5
6
7
       *> Compare last-updated-timestamp or version before rewrite
       IF INCOMING-VERSION NOT = STORED-VERSION
           DISPLAY 'Conflict: data changed by another process'
           PERFORM RESOLVE-STRATEGY  *> reload, merge, or abort
       ELSE
           REWRITE RECORD
       END-IF.

Use version numbers or timestamps to detect conflicts. When conflicts occur, choose resolution strategy: reload fresh data, merge changes, or abort the transaction.

Optimistic vs Pessimistic Locking

cobol

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
       *> Optimistic: assume no conflict, check at commit
       READ CUSTOMER-FILE
       COMPUTE NEW-BALANCE = CURRENT-BALANCE + AMOUNT
       MOVE NEW-BALANCE TO CURRENT-BALANCE
       REWRITE CUSTOMER-RECORD
       IF FILE-STATUS = '22'  *> record locked
           DISPLAY 'Conflict detected, retrying...'
           PERFORM RETRY-LOGIC
       END-IF.
 
       *> Pessimistic: lock before reading
       PERFORM OBTAIN-LOCK
       READ CUSTOMER-FILE
       COMPUTE NEW-BALANCE = CURRENT-BALANCE + AMOUNT
       MOVE NEW-BALANCE TO CURRENT-BALANCE
       REWRITE CUSTOMER-RECORD
       PERFORM RELEASE-LOCK.

Optimistic assumes low contention and checks for conflicts at commit time. Pessimistic locks up-front but can cause more blocking. Choose based on your contention patterns.

Deadlock Prevention

cobol

1
2
3
4
5
6
7
8
       *> Always lock in same order to prevent deadlocks
       IF CUSTOMER-ID < ACCOUNT-ID
           PERFORM LOCK-CUSTOMER-FIRST
           PERFORM LOCK-ACCOUNT-SECOND
       ELSE
           PERFORM LOCK-ACCOUNT-FIRST
           PERFORM LOCK-CUSTOMER-SECOND
       END-IF.

Establish consistent locking order across all programs. Use timeouts to detect and break deadlocks. Log deadlock occurrences for tuning.

Batch: design windows to avoid overlap; checkpoint often for recovery.
CICS: use transactional integrity; keep units short to reduce lock time.
Logging: capture conflicts and retries for audit and performance tuning.
Timeouts: detect and escape deadlocks automatically.
Order: lock resources in consistent order to prevent deadlocks.

Concurrent Access

Patterns for safe file sharing

CICS Programming

Transaction context and isolation