커넥션 획득시 데드락이 걸리는 상황도 발생할 수 있을까요?

말씀하신 데드락 문제는 --> 해당 식사하는 철학자 문제에서부터 이론적으로 많은 솔루션이 나왔습니다.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을 이용해 해당 데드락을 막을 것으로 생각됩니다.

커밋 순서를 바꾸면 안 되나요?

트랜젝션 전파 부분을 보시면 아시겠지만외부를 커밋을 해버리면 물리적 커넥션 자체를 다 그냥 커밋해버리는거라... 내부 커밋이 아마 안될겁니다.기실, 내부 커넥션을 커밋해버리면 그냥 내부적으로 존재하는 세이브포인트에 아 이 내부 트렌잭션 정상적으로 완료됬다고 찍히는 것으로만 알고 있습니다. 도움되셨으면 좋겠읍니다

외부 내부 모두 신규 트랜잭션인데, 외부커넥션을 먼저 반납하는경우

(사진)(사진)(사진)(사진)(사진)저게 outer 에서 inner 를 생성시켜도 transaction synchronisation을 관리하는거 같습니다..

트랜잭션 동기화 매니저 작동 원리

제가 알기로는 transactionManager들은 일종의 커넥션과 연결된 레퍼런스 포인터(참조값)을 유지하며, 해당 값을 넘기는 것으로 알고 있습니다.(일종의 OS에서 있는 프로세스? 간에 생기는 스택 프레임들의 경계선을 마킹하는 포인터값이랑 유사한 느낌..?)음...외부 트랜젝션 | 참조값 | 내부 트랜젝션 (참조값 알고 있음)이런 느낌일겁니다다만, 스프링이 제공하는 JtaTransactionManager에서는 다른 방식이 적용되는 것으로 알고 있습니다.이건 org.springframework.transaction.jta.JtaTransactionManager의 2 phase commit를 한번 검색해 보세요.여러 리소스로 분산되는 형식의 트랜젝션에 JTA 가 일반적인 JDBC 트랜젝션보다 더 효율적이라고만 알고 있어서..답변 도움 되셨으면 좋겠습니다

데이타소스없이 JpaRepository 작동하는 이유

인메모리 H2 db 사용하는것이 아니었나요...?