HIBERNATE SERIES - CUỐN SỔ

Lazy Loading: Tờ Giấy Hẹn Phải Quay Đúng Session

LAZY STATE - HAI NHÁNH + MỘT BỐI CẢNHĐây không phải ba tầng phóng to. Nhánh A và nhánh B là hai đường code song song, không đường nào gọi đường nào; cột cuối là bối cảnh quyết định cho cả hai.

Session đã đóng

order.getItems().size() chạm wrapper chưa initialized và ném LazyInitializationException.

Cùng một lời hứaLazy value chưa chứa dữ liệu. Nó giữ liên hệ với Session sinh ra nó và cần Session đó để chạy câu SELECT còn thiếu.

OSIV còn mở Session

Cùng getter chạy được ở web layer, nhưng có thể phát SQL ngoài service transaction và tạo N+1.

Nhánh A - collection wrapper

AbstractPersistentCollection

Đọc collection chưa initialized

  1. read() hoặc readSize()PersistentBag chuyển thao tác đọc vào base wrapper.
  2. initialize(false)Bao tác vụ load trong withTemporarySessionIfNeeded().
  3. session.initializeCollection(this, false)Gửi initialize event vào Session đang sở hữu wrapper.
  4. throwLazyInitializationExceptionIfNotConnected()Ném khi không còn Session, Session đóng hoặc mất kết nối. Chuỗi của nhánh này: failed to lazily initialize a collection of role: ... - không có ngoặc vuông.
  5. ENABLE_LAZY_LOAD_NO_TRANSCó thể mở temporary Session nếu bật, nhưng đổi boundary và chi phí query.
Nhánh B - entity proxy

AbstractLazyInitializer.initialize()

Proxy to-one có pipeline riêng

  1. Getter cần targetInterceptor của proxy gọi lazy initializer khi property không thể trả bằng identifier.
  2. isConnectedToSession()Kiểm tra proxy còn liên hệ với persistence context phù hợp.
  3. session.immediateLoad(entityName, id)Load target bằng Session nếu Session mở và kết nối.
  4. checkTargetState(session)Xử lý target null và semantics unwrap.
  5. LazyInitializationExceptionChuỗi của nhánh này có ngoặc vuông: could not initialize proxy [Entity#id] - no Session, và phân biệt tiếp the owning Session was closed / is disconnected.
Bối cảnh - web request boundary

OpenEntityManagerInViewInterceptor

Cả hai nhánh trên đều dừng ở cùng một câu hỏi: Session còn dùng được không?

  1. preHandle()Nếu chưa có holder, tạo EntityManager và bind vào thread.
  2. EntityManagerFactoryAccessor.createEntityManager()Kế thừa từ lớp cha, không khai trên chính interceptor. Persistence context sống xuyên suốt request web đồng bộ.
  3. Service transaction kết thúcTransaction đóng nhưng suất trong pool không được trả; nó ở lại tới khi EntityManager của OSIV đóng.
  4. View/Jackson chạm lazySession còn mở nên query có thể chạy ngoài transaction của service.
  5. Một @Transactional khác chạy sauEntity sửa ngoài transaction vẫn managed, nên commit của transaction này flush hộ: cú set tưởng rơi vào khoảng không lại được ghi. Không ai gọi save().
  6. afterCompletion()Unbind holder rồi đóng EntityManager ở cuối request - đây mới là lúc suất được trả.

Phép kiểm: tắt spring.jpa.open-in-view, gọi đúng endpoint và đặt breakpoint tại hai hàm initialize(). Ghi lại thread, transaction active, Session open, SQL count và metric pool tại chính thời điểm getter lazy chạy.

Thiết kế fetch theo use case

  • Load đủ dữ liệu trong transactionDùng projection, entity graph hoặc query fetch phù hợp endpoint.
  • Dựng DTO trước khi rời serviceKhông mang proxy và collection wrapper qua boundary web.
  • Đếm query, không đoánOSIV che exception nhưng không xóa chi phí lazy load.

Khi KHÔNG được kết luận

  • OSIV ghim connection từ đầu requestMở sổ tốn 0 suất - Hibernate lấy connection muộn nhất có thể. Suất bị lấy từ câu SQL đầu tiên, rồi giữ tới khi đóng sổ, tức hết request.
  • Tắt OSIV là tự hết N+1Nó làm query muộn nổ sớm; query trong transaction vẫn có thể N+1.
  • OSIV cứu được mọi cú chạm lazy@Async/@Scheduled chạy ở thread khác: túi khác, không sổ nào - nổ y hệt kể cả khi OSIV bật (afterConcurrentHandlingStarted()).
  • Mọi lazy value đều là Hibernate proxyTo-one proxy và persistent collection dùng class, event và đường initialize khác nhau.

Hai phép đo trên sổ mở kiểu OSIV. Trái: cái giá về connection - hai trật tự (chờ trước khi chạm lazy, và chạm lazy trước khi chờ) cho kết quả giống hệt nhau. Phải: mặt tối - entity sửa ngoài transaction vẫn managed, nên một @Transactional khác trong cùng request flush hộ.

mo so, chua chay gi           ->  0 suat
transaction cua service dong  ->  1 suat  <- KHONG nha
cho 300ms                     ->  1 suat
cham lazy                     ->  1 suat
DONG so                       ->  0 suat
con managed sau khi tx dong ?  true
note trong DB ngay sau cu set  ->  chua doi
sau MOT transaction khac       ->  DA DOI