[JS] typeorm을 활용한 트랜잭션 사용방법의 차이

아래 기록은 Javascript, Typeorm 사용을 기반으로 사용하는점 참고!

트랜잭션을 사용하는데에 있어서 지금까지 나는 아래의 구조로 사용했다.

case.1

const queryRunner = await this.dataSource.createQueryRunner(); //DB연결로 트랜잭션생성
await queryRunner.connect(); //트랜잭션 연결
await queryRunner.StartTransaction(); // 트랜잭션 시작

  try{
    .
    .
    .  
    .//트랜잭션을 사용한 이후에 세부적인 로직들
    await queryRunner.commitTransaction(); //트랜잭션을 사용한 세부적인 로직들 커밋
  }catch(err){
    await queryRunner.rollbackTransaction(); // 에러발생시 롤백
    console.error(err);
    throw err
  }finally{
    await queryRunner.release(); //트랜잭션 종료
}

그리고 새로운 개발환경의 코드를 보고 트랜잭션을 사용하긴하는데 다른형태(?)의 트랜잭션을 보게되었다.

case2.

const queryRunner=getConnection().createQueryRunner(); //트랜잭션 연결
await queryRunner.startTransaction(); // 트랜잭션 시작

try{
    .
    .
    .  
    .//트랜잭션을 사용한 이후에 세부적인 로직들
    await queryRunner.commitTransaction(); //트랜잭션을 사용한 세부적인 로직들 커밋
  }catch(err){
    await queryRunner.rollbackTransaction(); // 에러발생시 롤백
    console.error(err);
    throw err
  }finally{
    await queryRunner.release(); //트랜잭션 종료
}

참고사항(개정) : 작성날짜 기준의 typeorm의 최신버전에서는 getConnection()의 메소드를 사용할 수 없다는 점 참고!!!!!!!!!!!!!!!(중요) 다른 방법들도 많지만 DataSource를 활용하는 것을 춫현~~

아래의 try, catch, finally 문에 대해서는 사실 같은 맥락으로 시작된다.
하지만 변수 queryRunner를 정의하는데 있어서의 사용되는 메소드가 조금 다를 뿐이었다.

나는 이 내용을 보고 이 구성의 차이에 대해서 궁금해졌고 원리와 차이가 있을지 그리고 효율적인 측면에서의 차이가 있을수도 있는지 궁금해졌다.

내용은 찾아본 결과

Case 1과 Case 2는 두 가지 다른 방법으로 TypeORM에서 트랜잭션을 시작하는 방법을 나타냅니다. 두 경우 모두 트랜잭션을 사용하여 데이터베이스 작업을 원자적으로 실행하려는 목적을 가지고 있지만, getConnection() 및 this.dataSource의 차이로 인해 작동 방식에 차이가 있습니다.
주요 차이점은 데이터 소스의 사용 여부입니다. Case 2는 기본 연결을 사용하여 쿼리 러너를 생성하는 반면, Case 1는 별도의 데이터 소스를 사용하여 쿼리 러너를 생성합니다. 이로 인해 Case 1은 데이터 소스를 통해 명시적으로 연결을 수립하는 추가 단계(queryRunner.connect())가 필요합니다.
일반적으로 Case 1과 Case 2 중 어떤 방법을 선택할지는 프로젝트 또는 코드 구조에 따라 다를 수 있습니다. 예를 들어, 다중 데이터베이스 연결을 관리하는 경우 Case 1와 같이 별도의 데이터 소스를 사용하는 것이 유용할 수 있습니다. 그러나 간단한 경우나 기본 연결만 필요한 경우 Case 2과 같이 기본 연결을 사용하는 것이 더 간편할 수 있습니다.

Case 1과 Case 2의 효율은 주로 사용 사례와 코드 구조에 따라 달라진다. 효율성 측면에서 각각의 장단점이 있다:

• Case 1:

  장점:

  데이터 소스를 사용하여 다중 데이터베이스 연결을 관리하기에 더 유용하다.
  별도의 연결 관리를 할 수 있으므로 더 많은 제어권을 갖는다.

  단점:

  코드가 조금 더 복잡해질 수 있다.
  데이터 소스를 설정하고 관리해야 하므로 초기 설정과 관리에 시간이 더 걸릴 수 있다.

• Case 2:

  장점:

  간단하고 직관적인 코드다.
  기본 연결을 사용하므로 추가적인 연결 관리가 필요하지 않다.

  단점:

  프로젝트가 복잡하고 다중 데이터베이스 연결이 필요한 경우 유연성이 부족할 수 있다.

따라서 어떤 방법이 "더 효율적"인지는 사용 사례와 프로젝트 요구사항에 따라 다를 수 있다. 간단한 프로젝트에서는 Case 2이 효율적일 수 있지만, 복잡한 다중 데이터베이스 환경에서는 Case 1와 같이 데이터 소스를 사용하는 것이 더 효율적일 수 있다. 이러한 선택은 코드의 유지 관리, 확장성, 그리고 프로젝트 요구사항에 따라 다르다.

사용적인 측면에서 개개인이 사용하고자 하는 관성이 다르기 때문에 사용법이 다를 수 있지만 이런 내용에 대해서는 위의 장/단점을 생각해서 코드환경을 만들어 나가야하는 것으로 보인다.

case1로만 사용했던 나에게 새로운 사용법에 대해서 알 수 있어서 좋았고 선택에 맞추어 개발을 해야하겠다는 생각이 들었다.