예를 들어 PO item이 짧은 시간내에 여러번 일어나는 경우를 상정하여 본다면,

V1(enqueue 메카니즘)은 OLTP테이블이 정합성 있게 업데이트 된다는 가정하에서는 확실한 방법이다.

하지만 테이블이 업데이트 될때에 그 데이터가 BW에 전달될때는 순서대로 온다는 보장이 없다.

'Serialized V3' 방식은 update된 데이터를 순서대로 delta queue에 적재하므로 정합성이 확실하게 보장된다.

(delta queue에 쌓인 후 BW로 전달됨)

V3 job이 실행될때에 업데이트된 레코드들은 각각 타임스탬프를 가지고 있으므로, 레코드들은 정확하게

'Serialized'된 일련번호를 가지게 된다.

그러나 여기에는 기술적인 문제점이 존재하는데, 어플리케이션 서버로부터 업데이트된 레코드가 전송되어

타임스탬프가 기록될때 만약에 어플리케이션 서버가 여러 개라면 개별적인 서버의 시스템 시간으로 인해

일련번호의 정확성이 훼손될 여지가 있다.

또 다른 V3 프로세스 디자인의 근본적인 문제점은, V3 job이 타임스탬프에 의해 업데이트 되고나서 그 테이블로

부터 레코드가 업로드 되는데(델타큐로) 이때에는 한번에 한 언어만을 처리한다는 점이다.(update된 레코드는

유저가 로그온한 언어로 저장하고 있음)

만약, 사용자들이 여러 언어로 접속을 한다면 이는 잠재적인 이슈가 될 수도 있다. 이런 경우에는 Serialization은

정확하게 동작하지 않을 수도 있다.

첫번째 업데이트가 같은 PO item에서 EN(영어)으로 처리되었다고 가정하면, V3 job은 다른 순서의 언어로 된 레코드

처리이전에 EN에서의 시간 순서대로 모든 업데이트 레코드를 처리하게 될 것이다.

만약 다른 언어로 같은 PO item에서 EN으로 update처리하는 중간에 업데이트가 일어났다면,

EN의 처리가 모두 끝난 이후에 update가 이루어질텐데, 이는 sequence에 위배되는 것이다.

이러한 두 가지 제약조건은 'Serialized V3'의 'Serialization'이라는 명제를 충족하지 못하는 사항인데, 이에 따라

새로운 PI에서는 'Serialized V3'가 폐기되었고 아마 새로운 PI버전을 쓰고 있다면 이 방법은 더 이상

쓸 수 없을 것이다.

어쨌든 'Serialized V3'를 사용하고자 한다면, 'serialization'이라는 것이 위 두가지 사항 때문에

(멀티언어 환경, 그리고 다른  app서버에서 또는 같은 레코드가 같은 시간에 update될때)언제나 완벽할 수는

없다는 것을 유의하여야 한다.

- BW관련 컬럼 중 위 사항이 있어서 번역해보았습니다.