묻고 답해요

테이블 락 원인 궁금

미해결

지금 제가 신입으로 와서 SM 하고 있는 서비스는 JSP + Spring4로 진행하고 있습니다. 현재 테이블 락이 너무 자주 걸려서 (데드락) 계속 머리가 아픈 상황입니다. 이게 왜 걸릴까에 대해서 한번 고민하고 있는데, 혹시 이 추측이 맞을까요 ? (폐쇄망이라 AI를 전혀 못 쓰는 상황입니다..) 특정 서비스 (비즈니스 로직)마다 상단에 ex. @Inject private SupplyEvaluationResultDao supplyEvaluationDao; 이런 식으로 DI를 하고 있습니다. 그리고 @Autowired private DataSourceTransactionManager transactionManager; 이렇게 트랜잭션 메니저를 DI한 후 데이터를 업데이트 하는 서비스에서는 (U, D).. 서비스마다 DefaultTransactionDefination def = new DefaultTransactionDefinition(); def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); Transaction status = transactionManager.getTransaction(status); 이것들을 매번 선언하고 모든 과정이 통과하면 transactionManager.commit(status); 특정 과정 진행 중 오류가 발생하면 transactionManager.rollback(status); 를 하고 있습니다. 근데 이게 SM이다 보니까, 여럿이서 개발을 진행해서 transactionManager.commit() 이나 transactionManager.rollback()을 안하고 Map 형태로 그냥 RES_CODE에 오류 코드, RES_MSG에 오류 메시지만 담아서 반환하는 경우가 있습니다. 서비스 메서드 위에서는 TransactionStatus까지 그대로 적용은 하는데... resMap.put("RES_CODE", "0020"); resMap.put("RES_MSG", "파일은 금지된 형식입니다."); return resMap; 트랜잭션 상태를 가져온 후 commit 이나 rollback 없이 그대로 Map을 반환해버린 경우 혹시 테이블 락이 발생하는 것일까요 ? 트랜잭션 상태를 끝맺음을 안 내서 테이블 락이 걸리는 것인지 가능성이 있는 것일지 궁금합니다 !

• 데드락
• 락

안녕하세요? 여쭤볼 곳이 없어 질문남깁니다

미해결

실전! Querydsl

회사에서 MSSQL을 사용하고 있습니다 기존에 마이바티스를 사용하고 있었고 최근 JPA와 querydsl을 도입했습니다 MSSQL특성 상 SELECT 쿼리에 with(nolock) 힌트를 줘서 써야한다하기에 셀렉트 쿼리에 한하여 @Transactional (isolation = Isolation. READ_UNCOMMITTED ) 를 줬습니다 현재 배포시 의문의 락이 걸리고 있는 상황인데, 개발서버에서는 아무 이상이 없고 운영에만 넘어가면 락이걸리네요 아무튼 상황은 이렇구 제 의문은 이겁니다 with(nolock)힌트를 줘서 더티리드를 한다고 한다면 JPA는 어쨋건 읽어오면서 영속성 컨텍스트에 저장을 하게되잖습니까? 그럼 더티리드를 여러군데서 해간다고 한다면 정합되지 않은 해당 정보들이 모두 영속성 컨텍스트에 들어간 상태인데, 그 상황에 어딘가에서 변경감지를 통한 업데이트 쿼리가 발생한다고 한다면 이게 정확히 어떤식으로 동작하는지가 궁금합니다. 현재 발생하고 있는 의문의 락과 연관이 있을까요?

• 실무
• 락
• JPA
• java