인프런 커뮤니티 질문&답변
작성한 질문수
MySQLConfig 관련 질문있습니다.
해결된 질문
작성
·
110
0
선생님께서 말씀을 조금 두루뭉술하게 해주셔서인지 ㅠㅠ 다들 궁금해 하시는거같은데 저또한 궁금한 부분들이 있습니다.
JPA에서 처음부터 트랜잭션 매니저 구현체로
JpaTransactionManager를 사용하지 않고 auth쪽은DataSourceTransactionManager를 사용한건 왜 그런건가요?AuthService#createUser()부분에서는 일반 JDBC 기반의DataSourceTransactionManager를 사용하셨더라구요.이러한 경우 영속성 컨텍스트에서 Entity들의 생명주기까지는 관리가 안되는걸로 알고 있습니다. Lazy Loading이나 Dirty Check 등..
채팅관련 트랜잭션 설정할때에는 구체적으로 어떤 메커니즘에 의해 어떤 문제가 발생할 수 있는지 명확히 알려주실 수 있을까요? 제가 몇 번 돌려서 듣긴 했는데 느낌이 STOMP 통신 특성상 발생되는 이슈라고 이해는 한 것 같은데 그게 구체적으로 어떠 어떠한 이유로 오류가 발생한다?혹은 할수도 있다? 는것인지 이해를 못했습니다. 확실히 무조건 오류가 발생을 한다는걸까요? 그리고 그 원인은 무엇일까요?
단순히 JPA를 이용한 비즈니스 로직을 작성할때는
JpaTransactionManager가 관리하는 트랜잭션 내에서 작성하자. 그리고 그러기 위해서createChatTransacationMansger를 사용하자. 라고 이해해도 될까요?JpaRepository구현체인SimpleJpaRepository에는 기본적으로save()에는 트랜잭션이 걸려 있지만 저장 이후에 Entity 조작하는 로직이 있다면 동작하지 않게 되니까요..
혹시 일반적인 JPA 환경과 별개로 STOMP를 통한 웹소켓 통신 환경에서의 JPA 트랜잭션 처리에 대해 특이사항이 있었던거라면 자세히 설명좀 부탁드려도 될까요? 예를 들어 일반 MVC 프레임웍의 http 통신 환경일때는 스레드 또한 톰캣의 스레드를 사용하지만 STOMP는 환경이 달라서 뭔가 신경써야 할게 있다든지..?
감사합니다.
답변 2
1
안녕하세요 질문주신 부분에 대해서 확인해보았는데.. 결과를 한번 말씀드리도록 하겠습니다.
1. 명백히 저의 실수입니다.
말씀하신 부분처럼 JPA기반의 매니저를 사용해야하는데, JDBC기반의 매니저를 사용했었네요.. 오타가 발생한 부분인거 같습니다. 관련하여 수정 및 공지를 따로 진행하도록 하겠습니다. 확인해주셔서 감사합니다.
2, 3. 채팅관련 데이터를 다루는 행위 즉 Transcation에 대해서는 사실 큰 정답은 없는거 같습니다.
우선적으로 STOMP를 사용하기 떄문에 발생하는 이슈라기 보다는, 우리는 Spring에서 TrnasacitonManager 를 사용할꺼라소 Config 를 통해 선언하였기 떄문에, 자동으로 관리가 안해주는 상황으로 보시면 됩니다.
구체적인 부분은 저도 추가로 찾아봐야 할 부분인거 같은데.. 일단 실무에서 사용했을떄는 타임라인이 부족하여 해결하는데에 집중이 된 부분이 있습니다. 다시 복귀하면 찾아봐야 하는 부분인거 같네요. 큰 도움을 드리지 못해서 죄송스럽습니다.
마지막으로 몇가지 좀 더 추가적인 꿀팁??을 드리고자 합니다. 질문 내용이 너무 유익한 부분인거 같네요.
먼저 사실 채팅 데이터를 다루는 부분에 있어서는 단일 건수에 대해 Transaction 을 발생시키는 것은 꽤나 큰 자원 낭비 입니다.
트래픽 유형 자체가 무의미한 데이터도 많은 상황이기 떄문에 단건마다 처리하기보다는 Bulk 모델을 구현하여 사용하는게 좋습니다.
두번째로 사실 STOMP와 같은 소켓 통신을 통해서는 요청마다 데이터를 처리하지는 않습니다.
실제 채팅에 과련된 아키텍처는 소켓 통신은 단순히 Clinet와 통신하는 주체일 뿐입니다. 들어오는 요청에 대해서 단건마다 처리하는 경우도 있지만 좀 더 유연한 관계를 위해서 뒷단에 Kafka와 같은 메시징 툴을 활용하는 경우가 많습니다. 이러한 부분에 대해서도 한번 고민해 보시면 좋을 꺼 같아요.
쉽게 말씀드리면 이런 구조가 될 꺼 같네요.
Client -> LB -> STOMP -> Kafka -> DB 및 다른 Node 이 구조에서 LB가 붙게 되었을 떄, 소켓 서버간에 데이터 동기화를 위해 Kafka를 사용한다고 보시면 됩니다.
마지막으로 채팅관련된 내용은 아니지만 TrnascationManager 에 대해서 관심이 많으신거 같아 생각보다 간과하기 쉬운 readOnly 옵션에 대해서 말씀드리고 싶습니다.
아실수도 있겠지만, readOnly 는 Write 에 대한 Lock을 제외하라는 옵션으로 트랜잭션을 통해 읽기 처리를 최적화 하는 방법입니다.
하지만 해당 옵션이 동작하기 위해서는 기본적으로 tx을 연다 -> Option을 설정한다 -> 데이터를 읽는다 과정으로 동작을 해야 하고, 기본적인 Option 을 설정해야 한다는 추가적인 오버헤드가 발생합니다.
그래서 단일건수에 대해서 너무 남용하시게 된다면 의도치 않게 DB에 대한 부하가 발생가능하니 이러한 부분도 고민해 보시면 좋지 않을까 싶습니다.
질문에 대한 답변이 잘 되었는지 모르겠네요.. 좋은 부분을 지적해주셔서 좀 신이나다보다 많은 내용을 자잘자잘한 내용을 작성하게 된 거 같아요.. 혹시 도움이 되셨다면 기쁘겠습니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. dlsrksrhk님.
질문해 주신 내용은 JPA와 트랜잭션 매니저, 그리고 STOMP를 통한 웹소켓 통신에서의 트랜잭션 관리에 관한 것입니다. 이를 이해하는 데 도움이 될 수 있는 몇 가지 기존 답변을 찾아보았으니 참고해 보시기 바랍니다.
- JPA와 트랜잭션 매니저 선택 이유:
여러분의 첫 번째 질문에 관한 내용입니다. JpaTransactionManager와 DataSourceTransactionManager는 상황에 따라 선택되며, 각자의 특징이 있습니다. DataSourceTransactionManager는 JDBC 기반으로 작동하여 좀 더 범용적인 사용이 가능하고, JPA의 특수한 기능(예: Lazy Loading)은 사용하지 않는 경우에 유용합니다. 반면, JPA의 독특한 기능을 사용하려면 JpaTransactionManager가 더 적합합니다.
- STOMP와 웹소켓 통신에서의 트랜잭션 문제:
웹소켓 통신의 경우, 여러 클라이언트가 실시간으로 연결되기 때문에 트랜잭션 경계를 명확히 정의하지 않으면 데이터 일관성이 깨질 수 있습니다. 특히, STOMP 프로토콜의 특성상 비동기로 메시지를 주고받기 때문에 전통적인 트랜잭션 방식이 문제가 될 수 있습니다. 이러한 환경에서 발생할 수 있는 문제는 바로 데이터 동기화 오류입니다. 데이터의 정확성과 일관성을 유지하기 위해 트랜잭션 관리가 중요합니다.
- JPA 환경에서의 트랜잭션 관리 이해:
일반적인 JPA 비즈니스 로직에서는 JpaTransactionManager가 JPA의 영속성 컨텍스트를 처리하며 Lazy Loading 등의 기능을 지원합니다. 그러나 웹소켓과 통합된 환경에서는 상황에 따라 트랜잭션 범위를 더욱 명확히 지정해주는 것이 좋습니다. createChatTransacationManager를 사용함으로써 이러한 트랜잭션 경계를 강화할 수 있습니다.
이와 같은 내용들은 JPA와 트랜잭션, 그리고 웹소켓 통신의 특성을 명확히 이해하는 데 도움을 줄 것입니다. 더욱 깊이 있는 내용을 원하신다면, 강의 내용을 다시 참조하시면서 보다 실질적인 프로젝트 예제를 살펴보시는 것도 좋습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
ㅎㅎ 답변에 추가적인 꿀팁까지 주셔서 감사합니다. 더 좋은 강의 또 만들어주시면 들을게요ㅋㅋ