[ABAP] #30 LUW & Lock

 

 

 

 

 

 

 

 

LUW (Logical Unit of Work)

데이터베이스 작업의 단위를 의미하며, "모두 처리되거나, 하나도 처리되지 않아야 한다(All or Nothing)"는 원칙이 핵심

즉, 데이터 정합성을 보장하기 위한 개념이다.

 

LUW의 종류

SAP에서는 LUW를 2가지 관점으로 나눈다.

 

1. SAP LUW

• 업무 관점에서 논리적으로 하나의 작업 단위
• 여러 화면, 여러 프로그램, 여러 단계에 걸칠 수 있음
• 하나의 SAP LUW 안에 여러 개의 DB LUW가 포함될 수 있음
• 여러 화면이나 단계를 거쳐 입력받은 데이터를 최종 단계에서 한 번에 DB 반영하는 것이 일반적

화면 1 입력
 → 화면 2 입력
 → 화면 3 입력
 → 저장 버튼 클릭
 → COMMIT WORK

 

2. Database LUW (DB LUW)

• DB 관점의 작업 단위
• COMMIT WORK 또는 ROLLBACK WORK 기준으로 구분됨
• COMMIT WORK : 지금까지의 변경 내용을 DB에 영구 반영
• ROLLBACK WORK : 마지막 커밋 이후 변경 사항 전부 취소

INSERT ztable FROM wa.
UPDATE ztable FROM wa2.
COMMIT WORK.  " 여기까지가 하나의 DB LUW "

• DB는 COMMIT / ROLLBACK 전까지 변경 내용을 임시로 유지함

---

COMMIT / ROLLBACK 종류

 

1. 명시적 커밋 / 롤백

• 개발자가 아래 코드를 프로그램에 직접 작성.

COMMIT WORK.
ROLLBACK WORK.

 

 

2. 암묵적 커밋

• 화면이 변경되거나 비정상적으로 종료되었을 때
• RFC(remote function call) 함수가 호출되거나 종료되었을 때

 

3. 암묵적 롤백

• 덤프가 일어나거나 메시지 A 또는 X타입이 실행될 때

※ LOOP 안에서 COMMIT 금지

---

Work Process(WP)

 

SAP Application Server에서 실제로 ABAP 코드를 실행하는 “일꾼 프로세스”

사용자가 T-code를 실행하면 Dispatcher가 적절한 WP에 할당해서 처리하게 함.

 

WP 종류

1. D 타입 WP (Dialog WP)

• 화면(Dialog) 처리 담당

2. V 타입 WP (Update WP)

• DB 변경 작업 담당

[사용자 화면]
   ↓
D WP  (입력 처리)
   ↓  (COMMIT WORK)
V WP  (DB UPDATE)

---

 

화면 이동 시 암묵적 COMMIT이 발생하는 이유

• SAP는 기본적으로 "한 화면 = 하나의 논리 처리 단위"이다.
• 화면 이동 시 현재 D WP 작업 종료 → 다른 D WP로 넘어갈 수 있음
• 그래서 이전 작업 내용을 유지할 수 없기 때문에 시스템이 자동으로 LUW를 종료하면서 암묵적 COMMIT 발생

LUW란 정확히 뭐냐?

• LUW = 롤백이 가능한 작업 범위

따라서 COMMIT이 일어나면 LUW이 사라지고 새로운 LUW가 생성된다.

 

 

그래서 의도치 않은 DB 반영이 생길 수 있다.

---

Lock (잠금 관리)

여러 사용자가 동시에 같은 데이터를 수정할 때 데이터 일관성(Data Consistency)을 유지하기 위해 사용 한다.

(Lock 없으면 데이터 덮어쓰기 / 유실 발생)

 

Lock 종류

1. DB Lock

• DB가 자동 관리
• SQL 실행 시 발생
• 트랜잭션 단위
• COMMIT / ROLLBACK 시 해제
• 실제로 DB 변경 SQL 실행 시 DB Lock이 걸린다.
• 암묵적 커밋이 일어날 때 DB Lock도 함께 삭제된다.

 

2. SAP Lock

 

• ABAP 레벨에서 명시적으로 관리
• ENQUEUE / DEQUEUE 함수를 사용
• 메시지 서버 + Enqueue WP 사용
• 논리적 잠금 (Logical Lock)

 

※ SAP는 DB Lock에만 의존하지 않음 → 성능 + 분산 서버 환경 때문

 

※ SM12에서 락이 설정되어 있는 것을 확인할 수 있으며, 락을 삭제할 수도 있다.

---

Lock 처리 흐름

1. 프로그램에서 ENQUEUE를 호출하여 SAP Lock을 요청한다.

2. 메시지 서버를 통해 요청이 전달되면, Enqueue Work Process가 전역 Lock Table을 확인한다.

3. 이미 Lock이 존재하면 대기하거나 에러를 반환하고,
            Lock이 없으면 Lock을 설정한다.

4. 이후 로직 처리 및 DB 업데이트가 수행되며,
   COMMIT WORK 또는 ROLLBACK WORK로 LUW가 종료되면
   SAP Lock과 DB Lock이 함께 해제된다.

 

 

메시지 서버가 Lock을 관리하는 이유

=> SAP는 여러 Application Server를 사용하는 분산 시스템이기 때문에,

각 서버가 독립적으로 DB Lock을 걸면 서로 상태를 몰라 충돌이 일어날 수도 있다.

User A → App Server 1 → DB
User B → App Server 2 → DB

 

따라서, 중앙 집중형 Lock 관리 필요

그래서 메시지 서버를 통해 Enqueue WP가 전역 Lock Table 관리하는 것이다.

프로그램
  ↓
Message Server
  ↓
Enqueue WP
  ↓
Lock Table (전역)​

=> 어떤 서버에서든 같은 Lock 상태를 공유 가능

---

Lock Object 

• 어떤 테이블, 어떤 키로 잠글지 정의한다. (테이블을 락 걸수도, 테이블 필드를 대상으로 락 걸수도 있다.)
• SE11에서 생성하며 이름은 EZ~ 또는 EY~ 로 시작해야 한다.
• Lock Object를 만들면 ENQUEUE(잠금 설정)와 DEQUEUE(잠금 해제) 펑션 모듈이 자동으로 생성된다.

 

Lock 생성 방법

1. SE11에서 Lock Object를 생성한다.

 

2. Tables 탭에서 Lock을 걸 테이블명을 작성해주고 Lock Mode도 설정해준다.

 

3. 저장 후 활성화를 시켜주면 어플리케이션 툴바에 Lock Modules 버튼이 생성되고,

    DEQUEUE와 ENQUEUE 모듈이 자동으로 생성되어 있는 것을 확인할 수 있다.

 

---

ENQUEUE Parameter

CALL FUNCTION 'ENQUEUE_EZ_WORKB20'
  EXPORTING
    mode_<table_name>  = 'E'
    mandt              = sy-mandt
    <lock parameter>   = 1          " Lock Argument "
*   X_<lock parameter> = ' '
*   _SCOPE             = '2'
*   _WAIT              = ' '
*   _COLLECT           = ' '
  EXCEPTIONS
    foreign_lock     = 1
    system_failure   = 2
    OTHERS           = 3.

 

Lock Mode  - mode_<lock object name> : 데이터에 접근하는 성격

• S (Shared, 공유 잠금): 읽기 전용. 다른 사용자도 읽을 수는 있지만 수정은 불가능
• E (Exclusive, 배타적 잠금): 쓰기 잠금. 다른 사용자 접근 불가 (단, 내가 건 잠금에 대해서는 추가 잠금 가능)
• X (Exclusive Non-cumulative, 배타적 비누적 잠금): E 모드보다 강력. 자기 자신도 중복 잠금 불가, 데이터 정합성 최우선
• O (Optimistic, 낙관적 잠금): 처음엔 잠금을 걸지 않고 있다가, 실제 업데이트 시점에 E 모드로 승격(Promote), 충돌 가능성 낮을 때 사용

_SCOPE : 잠금의 유효 범위를 결정

• 1: 프로그램 내에서만 유효
• 2: 업데이트 프로세스까지 전달 (기본값)
• 3: 프로그램과 업데이트 프로세스 모두 유효

_WAIT : 다른 사람이 이미 잠금을 걸어두었을 때 어떻게 할 것인지 결정

• Space (기본값): 누군가 잠그고 있다면 즉시 sy-subrc = 1을 뱉고 종료. 사용자에게 "누군가 수정 중입니다"라고 바로 알릴 때 사용
• X: 잠금이 풀릴 때까지 일정 시간(시스템 설정값) 동안 기다렸다가 다시 시도

_COLLECT : 잠금을 즉시 실행할지, 아니면 임시 보관함(Lock Container)에 담아두었다가 한꺼번에 보낼지 결정

• Space (기본값): 호출 즉시 Enqueue 서버에 잠금을 요청
• X: 로컬 가방에 담아만 둠. 나중에 FLUSH_ENQUEUE 함수를 불러야 실제 잠금이 발생 (성능 최적화용)

X_<lock parameter> : 특정 필드가 비어있는(Initial) 상태의 데이터도 잠글 것인지 결정

• Space (기본값): 파라미터로 넘긴 값과 일치하는 데이터만 잠금
• X: 해당 필드가 비어있는 상태의 레코드도 잠금 대상에 포함

---

Lock Argument

어떤 “범위(키 값)”까지 잠글 것인지 결정하는 값이다.

즉, 테이블 전체에 락을 거는게 아닌 특정 범위에 해당하는 데이터들을 잠그기 위한 기준 값이다.

 

예를 들어,

고객 테이블에 아래와 같이 데이터가 들어있다고 가정하면

KUNNR	NAME
1000	A
2000	B

 

▶ Lock Argument가 없음

ENQUEUE_EZ_CUSTOMER

• 고객 테이블 전체 잠김
• A가 1000번 수정 중
• B는 2000번도 수정 불가

▶ Lock Argument가 있음

ENQUEUE_EZ_CUSTOMER
  EXPORTING
    kunnr = '1000'.

• 1000번 고객만 Lock
• 2000번 고객은 다른 사람이 수정 가능

---

CALL FUNCTION 'ENQUEUE_EZ_WORKB20'
  EXPORTING
    mode_zdbwork_b20 = 'E'
    mandt            = sy-mandt
    workno           = 1
*   X_WORKNO         = ' '
*   _SCOPE           = '2'
*   _WAIT            = ' '
*   _COLLECT         = ' '
  EXCEPTIONS
    foreign_lock     = 1
    system_failure   = 2
    OTHERS           = 3.

IF sy-subrc <> 0.
  WRITE: '실패'.
ELSE.
  WRITE: '성공'.
ENDIF.

" 여기 사이에서 db update를 하는게 좋음 "

CALL FUNCTION 'DEQUEUE_EZ_WORKB20'
 EXPORTING
   MODE_ZDBWORK_B20       = 'E'
   MANDT                  = SY-MANDT
   WORKNO                 = 1
*   X_WORKNO               = ' '
*   _SCOPE                 = '3'
*   _SYNCHRON              = ' '
*   _COLLECT               = ' '
  .

* CALL FUNCTION 'DEQUEUE_ALL'. " 모든 락 해제

---

Update Task

화면 처리 중에는 DB에 직접 UPDATE 하지 않고, COMMIT WORK 시점에 한 번에 DB 업데이트를 수행하기 위한 SAP의 메커니즘이다.

 

 

 

Update Task가 필요한 이유

 

• 화면 1 → 화면 2 → 화면 3
• 매 화면마다 DB UPDATE 발생

만약 중간에 에러가 발생하면

 

• 이미 일부 데이터는 DB에 반영됨
• 롤백 불가능
• 데이터 불일치 발생

 

 

그래서 DB 업데이트는 미루고(Global Data에 저장) 마지막에 한 번에 실행

화면 1 → 데이터 임시 보관
화면 2 → 데이터 임시 보관
화면 3 → 저장
          ↓
       COMMIT WORK
          ↓
       DB 일괄 반영

 

---

Update Task 기본 구조

[화면 처리 단계]
Dialog WP (D WP)
- Enqueue Lock 설정
- 데이터 검증
- CALL FUNCTION ... IN UPDATE TASK (Update 요청 등록)

[저장 시점]
COMMIT WORK / COMMIT WORK AND WAIT
          ↓
Update WP (V WP)
- Update Function Module 실행
- DB UPDATE 수행
          ↓
Lock 해제
LUW 종료

 

CALL FUNCTION … IN UPDATE TASK

CALL FUNCTION 'Z_UPDATE_FM'
  IN UPDATE TASK
  EXPORTING
    is_data = gs_data.

 

• 즉시 실행 X
• Update Queue에 등록만 됨
• COMMIT WORK 때 실행됨

---

 

Lock Duration

 

• Lock은 Dialog WP에서 설정
• Update Task 실행이 끝날 때까지 유지
• COMMIT / ROLLBACK 시 해제

 

 

---

PERFORM … ON COMMIT / ON ROLLBACK

현재 LUW가 COMMIT / ROLLBACK 될 때 실행할 서브루틴(FORM)을 예약하는 기능이다.

즉, FORM을 즉시 실행하지 않고 COMMIT / ROLLBACK 시점에 실행하도록 “등록”하는 구문

PERFORM update_routine ON COMMIT.
PERFORM cleanup_routine ON ROLLBACK.

※ USING / CHANGING 불가 이유

COMMIT 시점에는:

• 호출 스택 없음
• 화면 컨텍스트 없음
• 파라미터 전달 보장 불가

 

 

LUW가 ROLLBACK 되면

• ON COMMIT에 등록된 FORM ❌ 실행 안 됨
• ON ROLLBACK에 등록된 FORM만 실행

---

Update Module (Update Function Module)

 

• Function Group 내에 정의된 Update 전용 Function Module
• 속성: “Update Module”
• COMMIT 이후 별도의 Update Work Process에서 실행되므로 Import 파라미터만 허용된다.
• 롤백이나 커밋을 사용할 수 없기 때문에 메시지 타입을 사용한다.

---

Update Mode

1. 비동기

COMMIT WORK.

 

• D WP는 바로 다음 처리
• V WP는 백그라운드에서 실행
• 병렬 처리

 

2. 동기

COMMIT WORK AND WAIT.

 

• D WP가 V WP 완료까지 대기
• Update 실패 즉시 감지 가능
• LUW1 종료 후 LUW2 시작

 

 

3. 로컬

SET UPDATE TASK LOCAL.

 

• V WP 사용 안 함
• 같은 WP에서 실행
• 디버깅용 / 특수 케이스
• 현재 LUW 동안만 유효

 

---

V Work Process (V1 / V2)

v 워크 프로세스는 v1과 v2로 나뉜다.

 

1. V1

• 핵심 DB 업데이트
• 실패하면 전체 롤백
• 가장 중요

2. V2

• 통계, 로그, 이력
• 실패해도 전체 영향 없음

※ 실행 순서 : V1 먼저 → 성공 후 V2