programing

JPA/Hibernate에서의 flash()의 올바른 사용

shortcode 2022. 9. 29. 23:52
반응형

JPA/Hibernate에서의 flash()의 올바른 사용

flush() 메서드에 대한 정보를 수집하고 있었는데 언제 사용해야 하는지, 어떻게 사용해야 하는지 잘 모르겠습니다.필자가 읽은 바로는 영속 컨텍스트의 내용이 데이터베이스와 동기화되는 것으로 알고 있습니다. 즉, 미결 스테이트먼트를 발행하거나 엔티티 데이터를 갱신하는 것입니다.

두 개의 엔티티가 있는 다음 시나리오가 있습니다.A그리고.B(단, JPA에 의해 강제되거나 모델링되지 않은 일대일 관계). A에는 수동으로 설정된 복합 PK와 자동 생성된 ID 필드가 있습니다.recordId.이것.recordId엔티티에 기입해야 합니다.B에 대한 외래어로서A절약하고 있다A그리고.B한 번의 거래로.문제는 자동 생성된 값이A.recordId를 명시적으로 호출하지 않는 한 트랜잭션 내에서 사용할 수 없습니다.em.flush()전화한 후에em.persist()A(IDENTY PK가 자동으로 생성된 경우 엔티티에서 값이 직접 업데이트되지만 여기에는 해당되지 않습니다.)

할 수 있다em.flush()트랜잭션 내에서 사용할 때 어떤 위해가 발생합니까?

아마 의 정확한 세부사항일 것이다.em.flush()구현에 의존합니다.일반적으로 Hibernate와 같은 JPA 공급자는 사용자가 실제로 트랜잭션을 커밋할 때까지 데이터베이스에 전송해야 하는 SQL 명령을 캐시할 수 있습니다.예를 들어, 전화한 경우em.persist(), 휴지 상태에서는, 데이타베이스의 INSERT를 작성할 필요가 있는 것을 기억합니다만, 실제로는 트랜잭션을 커밋할 때까지 이 명령을 실행하지 않습니다.그러나, 이것은 주로 퍼포먼스상의 이유로 행해집니다.

SQL 명령을 즉시 실행하는 경우가 있습니다.일반적으로 자동 생성 키나 데이터베이스 트리거 등의 부작용 결과가 필요한 경우입니다.

뭐?em.flush()는 내부 SQL 명령 캐시를 비운 후 즉시 데이터베이스로 실행하는 것입니다.

결론: SQL 명령을 데이터베이스로 보내는 최적의 타이밍에 대한 JPA 프로바이더의 결정을 무시하기 때문에 성능 저하가 발생할 수 있습니다.

em.flush()는 트랜잭션 내에서 사용할 때 해를 끼칠 수 있습니까?

예, 필요 이상으로 오랫동안 데이터베이스에 잠금을 유지할 수 있습니다.

일반적으로 JPA를 사용할 때 컨테이너에 트랜잭션 관리를 위임합니다(일명 CMT - 비즈니스 메서드에 대한 @Transactional 주석 사용). 즉, 메서드 입력 시 트랜잭션이 자동으로 시작되고 마지막에 커밋/롤백됩니다.EntityManager가 데이터베이스 동기화를 처리하도록 하면 sql 문의 실행이 커밋 직전에만 트리거되므로 데이터베이스의 수명이 짧아집니다.그렇지 않으면 수동으로 플러시된 쓰기 작업이 수동 플러시와 자동 커밋 사이에 잠금을 유지할 수 있습니다. 이 잠금은 남은 메서드 실행 시간에 따라 길어질 수 있습니다.

일부 조작은 플래시를 자동으로 트리거합니다.같은 세션에 대해 네이티브 쿼리를 실행하고(SQL 쿼리에 의해 도달하려면 EM 상태를 플러시해야 합니다), 네이티브 생성 ID를 사용하여 엔티티를 삽입합니다(데이터베이스에 의해 생성된 ID를 사용하여 insert 문을 트리거해야 합니다.따라서 EM은 생성된 ID를 취득하고 적절하게 man을 실행할 수 있습니다).연령 관계)

정말로.em.flush()캐시된 SQL 명령어만 전송하는 것이 아닙니다.퍼시스텐스 콘텍스트를 기본 데이터베이스와 동기화하려고 합니다.캐시에 동기화할 컬렉션이 포함되어 있는 경우 프로세스에서 많은 시간이 소비될 수 있습니다.

사용상의 주의.

언급URL : https://stackoverflow.com/questions/4275111/correct-use-of-flush-in-jpa-hibernate

반응형