말씀하신 데드락 문제는 --> 해당 식사하는 철학자 문제에서부터 이론적으로 많은 솔루션이 나왔습니다. https://namu.wiki/w/%EC%8B%9D%EC%82%AC%ED%95%98%EB%8A%94%20%EC%B2%A0%ED%95%99%EC%9E%90%20%EB%AC%B8%EC%A0%9C#:~:text=%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C%EC%9D%98%20%EA%B5%90%EC%B0%A9(%EB%8D%B0%EB%93%9C%EB%9D%BD)%EC%83%81%ED%83%9C,%EC%A7%81%EA%B4%80%EC%A0%81%EC%9C%BC%EB%A1%9C%20%EC%95%8C%20%EC%88%98%20%EC%9E%88%EB%8B%A4 . 아마 커넥션 풀 내부적으로 자바 synchronised 문 (모니터) 를 사용해 mutual exclusion을 이용해 해당 데드락을 막을 것으로 생각됩니다.
트랜젝션 전파 부분을 보시면 아시겠지만 외부를 커밋을 해버리면 물리적 커넥션 자체를 다 그냥 커밋해버리는거라... 내부 커밋이 아마 안될겁니다. 기실, 내부 커넥션을 커밋해버리면 그냥 내부적으로 존재하는 세이브포인트에 아 이 내부 트렌잭션 정상적으로 완료됬다고 찍히는 것으로만 알고 있습니다. 도움되셨으면 좋겠읍니다
제가 알기로는 transactionManager들은 일종의 커넥션과 연결된 레퍼런스 포인터(참조값)을 유지하며, 해당 값을 넘기는 것으로 알고 있습니다.(일종의 OS에서 있는 프로세스? 간에 생기는 스택 프레임들의 경계선을 마킹하는 포인터값이랑 유사한 느낌..?)음... 외부 트랜젝션 | 참조값 | 내부 트랜젝션 (참조값 알고 있음) 이런 느낌일겁니다 다만, 스프링이 제공하는 JtaTransactionManager 에서는 다른 방식이 적용되는 것으로 알고 있습니다. 이건 org.springframework.transaction.jta.JtaTransactionManager 의 2 phase commit 를 한번 검색해 보세요.여러 리소스로 분산되는 형식의 트랜젝션에 JTA 가 일반적인 JDBC 트랜젝션보다 더 효율적이라고만 알고 있어서.. 답변 도움 되셨으면 좋겠습니다
도움이 될 지는 모르겠지만 아마 그 처음 db 에 커넥션을 날릴 때의 host 파라미터에 따라 다르지 않을까요..? MySQL :: MySQL Connector/J 8.1 Developer Guide :: 9.4 Configuring Source/Replica Replication with Connector/J ``` replication is configured at the initial setup stage of the server connection by the connection URL, which has a similar format as the general JDBC URL for MySQL connection , but a specialized scheme: ```
그 DB 1편인가? 쯤에서 나왔을텐데 Spring boot initialisation 시 HikariPool에서 미리 데이터베이스와 커넥션을 생성(generation) 한 다음 연결 쓰레드를 저장하게 됩니다. 그리고 Transaction 이 서비스에서 시작을 하면 HikariPool(커넥션 풀) 에 저장된 이 쓰레드를 참조하게 되는데요, 이때 이걸 acquiring Connection이라고 하는 것으로 알고 있습니다. 도움 되셨길 바랍니다
