Hibernate의 generated query와 MSSQL의 nolock 힌트에 대한 고찰
하이버네이트와 같은 OR매핑 도구를 이용하게되면 개발자가 SQL 를 작성할 필요가 없어지고 ( 물론, createSQLQuery() 메소드를 통해 native query를 작성할 수 있지만 이번글의 주제와는 조금 다른 이야기이니 제쳐두자. ) OR매퍼에서 생성된 쿼리가 실행되는데 MSSQL과 hibernate를 이용할때는 한 가지 특수한 상황에 맞딱드리게 된다.
바로 select lock.
MSSQL, Sybase, DB2는 여타 DBMS와는 달리 select 쿼리에도 row level lock ( 트랜젝션이 몰리면 이 lock도 에스컬레이션해서 row -> page -> table lock으로 범위가 확대 )을 거는데 일반적인 web application을 개발하는데 select lolock은 DB성능을 떨어트리는 원인이되기때문에 대게 select 쿼리에 각 테이블에 with(nolock) 힌트를 줘서 락을 걸지 않도록 처리한다.
이제 Hibernate로 돌아와서, hibernate에 의해 generate된 쿼리에는 with(nolock) 옵션이 기본 적용이 되지 않는다. MSSQL에서 그냥 이용해도 하이버네이트 캐시시스템의 덕으로 문제가 발생하지 않을 수도 있지만 쿼리 실행 시 부하를 줄일 수 있는 방안이 있다면 적용하지 않을 이유가 없다.
이와 같은 내용은 검색 엔진에 hibernate mssql nolock 등의 키워드로 찾아보면 많은 결과를 확인할 수 있다. 그 중에 https://forum.hibernate.org/viewtopic.php?f=1&t=934158 의 쓰레드를 통해 확인한 방법은 다음과 같다.
[code]
session.connection().setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
[/code]
물론, MSSQL의 READ COMMITTED 격리수준 등 더 깊이있는 주제들도 있지만 내가 DB Geek도 아니고... 프로그래머 입장에서 요 정도까지만..
바로 select lock.
MSSQL, Sybase, DB2는 여타 DBMS와는 달리 select 쿼리에도 row level lock ( 트랜젝션이 몰리면 이 lock도 에스컬레이션해서 row -> page -> table lock으로 범위가 확대 )을 거는데 일반적인 web application을 개발하는데 select lolock은 DB성능을 떨어트리는 원인이되기때문에 대게 select 쿼리에 각 테이블에 with(nolock) 힌트를 줘서 락을 걸지 않도록 처리한다.
이제 Hibernate로 돌아와서, hibernate에 의해 generate된 쿼리에는 with(nolock) 옵션이 기본 적용이 되지 않는다. MSSQL에서 그냥 이용해도 하이버네이트 캐시시스템의 덕으로 문제가 발생하지 않을 수도 있지만 쿼리 실행 시 부하를 줄일 수 있는 방안이 있다면 적용하지 않을 이유가 없다.
이와 같은 내용은 검색 엔진에 hibernate mssql nolock 등의 키워드로 찾아보면 많은 결과를 확인할 수 있다. 그 중에 https://forum.hibernate.org/viewtopic.php?f=1&t=934158 의 쓰레드를 통해 확인한 방법은 다음과 같다.
[code]
session.connection().setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
[/code]
물론, MSSQL의 READ COMMITTED 격리수준 등 더 깊이있는 주제들도 있지만 내가 DB Geek도 아니고... 프로그래머 입장에서 요 정도까지만..
Trackback Address:이 글에는 트랙백을 보낼 수 없습니다