반응형

dead lock은 세션에서 대기하는 lock이 dead lock인지 아닌지 검사하는 시간을 lock을 대기 하자 마자 체크하지 않고, 일정 시간이 지난 후에 체크 합니다.

이유는 해당 lock이 서로 참조하고 있는지를 체크 하기 위해서는 내부적으로 체크하는 로직이 수행되어야 하므로, 매번 lock 대기시에 체크를 하게 되면 불 필요한 리소스를 사용하게 되고, 해당 lock 대기가 금방 끝날 경우 dead lock 체크를 위한 불필요한 리소스 사용을 하지 않게 하기 위함입니다.

그래서 lock을 대기 하고 일정 시간이 지난 후에 dead lock인지 여부를 체크 합니다.

 

아래의 테스트를 보시면 이해가 되시리라 생각 됩니다.

 

오라클 테스트 #1 : 세션1의 id = 2 업데이트가 lock 대기를 먼저 하고, 해당 lock 대기가 dead lock인지를 체크하는 시간이 먼저 도달 하기 때문에 세션 1이 dead lock으로 rollback 

 

PostgreSQL 테스트 #1 : dead lock 체크가 1초 이므로, lock 대기 후 1초가 지난 후에 dead lock을 체크 하는데, 세션 1의 id = 2 쿼리 후에 세션2에서 id = 1 업데이트 문 수행 전에 1초가 지나 가므로, 세션 1의 dead lock을 체크하는 시기에는 dead lock 상태가 아니였으므로 세션2가 dead lock 으로 rollback 

 

PostgreSQL 테스트 #2 : dead lock 체크를 10초로 변경 하였으므로, 세션 1에서 id = 2 쿼리 수행(lock 대기) 후 세션2에서 id =1을 할 때가 10초가 지나지 않은 시점이므로 세션 1의 dead lock 체크 시점에 세션2 업데이트로 인해서 dead lock 상태이므로 먼저 검사 대상인 세션 1이 rollback 

 

postgreSQL 테스트 #3 : 세션 1의 업데이트 이후 10초가 지나서 세션1에 대한 dead lock 검사가 지난 시점에 세션 2에서 update를 수행하게 되면 세션2의 마지막 업데이트만 dead lock 체크 대상이 되므로  세션 2의 업데이트가 dead lock으로 인한 rollback 

 

오라클 테스트 #2 : 위와 마찬가지 이유로 세션2가 dead lock으로 인한 rollback

 

 

반응형

+ Recent posts