logical unit of work = LUW
내가 어떤 트랙잭션을 마무리하는 일련의 유닛
DB LUW 과 SAP LUW를 맞춰 내는것이 업데이트 테크닠
거기에 사용되는것이 all or nothing 전부다 들어가거나 아무것도 들어가지 않는게 중요한 원칙
중간에 roll back 이 가능하지만 commit이 되면 더 이상의 roll back은 안되는 것
performance가 약한 컴퓨터로 많은 유저가 붙어있어도 high performance work process 가 시분할로 처리하고 DB형태 안에 one to one으로 붙어있다는 의미 ...
work process 가 굉장히 비싼 장비.. 더많은 resource 활용을 위해 화면이 바뀔 때마다 불필요한 commit을 하는 이유는 빨리 처리하고 다른 user의 입력을 기다리기 위함.
process를 완벽하게 살려두는 ->> 효율적으로 동작하기 위해
(끝나지도 않은 작업을 commit을 하는 이유 )
lock read update unlock => perform 구문 들어오기 전에 lock
flow logic은 불가능 module ( ABAP )에서 lock을 걸어주는 것
cancel : update . new : creation
정석 call subscreen 이면 위아래로 있어야 함.
subscreen pbo에 있으면 보여주고 pai에서 subscreen의 데이터를 아밥으로 밀어주기 위해서
없다면 뽑아줄 필요가 없음. read only임을 알 수 있음.
있어도 상관없음. 안쓰면 되기때문에 에러가 나지않음
lock 을 걸어주고 풀어주는 function 2개를 만들어 줌 .
언제 만들지 풀지, 다양한 lock 모드
DB commit이 이뤄지는동안 lock을 잡고 있다가 작업이 끝나면 lock을 놓는.
실질적으로 lock이 어떻게 작업하는지
work bench , message server에서 다뤘던 이야기들
MS 는 dispatcher와 GW는 내외부 연결
MS 는 디스패처와 통신을 담당.
lock server 의 메모리에 존재
자동으로 만들어지는 것
perform구문 들어가기 전 perform 수행. back 으로 빠져나올 때 dequeue로 풀어주는 것
락은 프로그램이 끝나면 자동으로 해제. 그래서 dequeue
위에 2개는 read/ write
o락이 s락보다 한단계 더 높다고 볼 수 있음
e와 x는 특성이 다름
S -> read으로 들어오는 경우 slock을 걸었을 때 write로 lock을 바꾸는게 불가능 ( 승격R한다고 표현) 허용하지 않음
여러 사람이 read로 들어올 수는 있음
o -> read로 들어와서 다중 접속은 가능하지만 한명이 write로 R(승격) 되면 다른 read lock들은 접속이 팅겨지는 것
o -> 잠재적 수정을 하려고 하고 s도 볼 수 있는데 o=s 는 같다고 생각하면 되지만 주의할 점은 o와 s가 함께 들어와 있을 경우 s는 승격이 안되지만 o는 승격이 되서 e로 승격 후 다른 s들을 팅겨낼 수 있음.
accumulation 은 e lock - unlock ( 다른 프로그램이 들어오면 안됨 )
pessimistic 안정적인 lock
read를 하기전에 write lock을 먼저 걸고 read를 하고 write를 하고 update를 하고 lock을 풀고
업데이트도 마찬가지로 해야함 .
왜냐면 다른게 들어올 수 없으니까
sm 12 lock table
list를 누르면 본인의 lock table 이 보임
수정할거면 refresh
se38
본인프로그램 열기
display 로
pattern 으로 자기 프로그램 가지고 오기
sflight.
주석 풀고
write lock 이라서 default값으로 가져가기위해 다 지우고
받는 값을 모를 땐 f1 누르고 포워딩
값 넣어주기
a message는 lock 이기 때문에
e message로 넣어주기
쓸데없이 많은 lock을 걸지 말기.
save, back, cancel 일 때 디큐.
exit 안해줘도 됨 프로그램을 종료할 때는 자동으로 해지