เหตุใด Hibernate Open Session in View จึงถือเป็นการปฏิบัติที่ไม่ดี

108

และคุณใช้กลยุทธ์ทางเลือกประเภทใดในการหลีกเลี่ยง LazyLoadExceptions?

ฉันเข้าใจว่าเซสชันที่เปิดอยู่ในมุมมองมีปัญหากับ:

แอปพลิเคชั่นแบบเลเยอร์ที่ทำงานใน jvm ที่แตกต่างกัน
การทำธุรกรรมจะเกิดขึ้นในตอนท้ายเท่านั้นและส่วนใหญ่คุณอาจต้องการผลลัพธ์มาก่อน

แต่ถ้าคุณรู้ว่าแอปพลิเคชันของคุณทำงานบน vm เดียวทำไมไม่คลายความเจ็บปวดของคุณโดยใช้กลยุทธ์การดูเซสชันแบบเปิด

— HeDinges
แหล่งที่มา

12

OSIV ถือเป็นการปฏิบัติที่ไม่ดีหรือไม่? โดยใคร?

— Johannes Brodwall

4

และ - ทางเลือกอื่นที่ดีคืออะไร?

— David Rabinowitz

7

ความสงบของข้อความนี้หากมาจากผู้พัฒนาตะเข็บ: มีปัญหาหลายประการในการใช้งานนี้สิ่งที่ร้ายแรงที่สุดคือเราไม่สามารถมั่นใจได้ว่าธุรกรรมจะประสบความสำเร็จจนกว่าเราจะยอมรับ แต่เมื่อถึงเวลาที่มีการทำธุรกรรม "เซสชันที่เปิดอยู่ในมุมมอง" มุมมองถูกแสดงผลอย่างสมบูรณ์และการตอบสนองที่แสดงผลอาจถูกล้างไปยังไคลเอนต์แล้ว เราจะแจ้งให้ผู้ใช้ทราบได้อย่างไรว่าการทำธุรกรรมของพวกเขาไม่สำเร็จ

— darpet

และนี่คือลิงค์: redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/seam/…

— darpet

2

ดูบล็อกโพสต์นี้เพื่อดูข้อดีข้อเสียและประสบการณ์ของฉันเอง - blog.jhades.org/open-session-in-view-pattern-pros-and-cons

— Angular University

46

เนื่องจากการส่งพร็อกซีที่ไม่ได้กำหนดค่าเริ่มต้นอาจเป็นไปได้โดยเฉพาะคอลเลกชันในเลเยอร์มุมมองและการเรียกใช้การโหลดแบบไฮเบอร์เนตจากที่นั่นอาจเป็นปัญหาทั้งจากมุมมองด้านประสิทธิภาพและความเข้าใจ

ความเข้าใจ :

การใช้ OSIV 'ก่อให้เกิดมลพิษ' ในเลเยอร์มุมมองโดยมีข้อกังวลเกี่ยวกับชั้นการเข้าถึงข้อมูล

เลเยอร์มุมมองไม่ได้เตรียมที่จะรับมือกับสิ่งHibernateExceptionที่อาจเกิดขึ้นเมื่อขี้เกียจโหลด แต่น่าจะเป็นชั้นการเข้าถึงข้อมูล

ประสิทธิภาพ :

OSIV มีแนวโน้มที่จะดึงเอนทิตีที่เหมาะสมโหลดใต้พรม - คุณมักจะไม่สังเกตว่าคอลเล็กชันหรือเอนทิตีของคุณเริ่มต้นอย่างเฉื่อยชา (อาจเป็น N + 1) สะดวกมากขึ้นควบคุมน้อยลง

อัปเดต:โปรดดูที่รูปแบบการต่อต้าน OpenSessionInViewสำหรับการสนทนาเพิ่มเติมเกี่ยวกับเรื่องนี้ ผู้เขียนแสดงประเด็นสำคัญสามประการ:

การเริ่มต้นแบบขี้เกียจแต่ละครั้งจะทำให้คุณได้รับข้อความค้นหาซึ่งหมายความว่าแต่ละเอนทิตีจะต้องมีการสืบค้น N + 1 โดยที่ N คือจำนวนการเชื่อมโยงแบบ lazy หากหน้าจอของคุณแสดงข้อมูลแบบตารางการอ่านบันทึกของไฮเบอร์เนตเป็นคำใบ้ที่สำคัญที่คุณไม่ได้ทำเท่าที่ควร

สิ่งนี้เอาชนะสถาปัตยกรรมแบบเลเยอร์ได้อย่างสิ้นเชิงเนื่องจากคุณทำเล็บของคุณด้วย DB ในเลเยอร์การนำเสนอ นี่เป็นข้อขัดแย้งทางความคิดดังนั้นฉันสามารถอยู่กับมันได้ แต่มีข้อพิสูจน์

สุดท้าย แต่ไม่ท้ายสุดหากมีข้อยกเว้นเกิดขึ้นในขณะเรียกเซสชันจะเกิดขึ้นระหว่างการเขียนเพจ: คุณไม่สามารถนำเสนอหน้าข้อผิดพลาดที่สะอาดแก่ผู้ใช้และสิ่งเดียวที่คุณทำได้คือเขียนข้อความแสดงข้อผิดพลาดในเนื้อหา

— Robert Munteanu
แหล่งที่มา

13

โอเคมัน 'ก่อมลพิษ' ในเลเยอร์มุมมองโดยมีข้อยกเว้นไฮเบอร์เนต แต่เกี่ยวกับประสิทธิภาพฉันคิดว่าปัญหาค่อนข้างคล้ายกับการเข้าถึงชั้นบริการที่จะคืนค่า dto ของคุณ หากคุณประสบปัญหาด้านประสิทธิภาพคุณควรเพิ่มประสิทธิภาพปัญหาเฉพาะนั้นด้วยแบบสอบถามที่ชาญฉลาดขึ้นหรือ dto ที่มีน้ำหนักเบามากขึ้น หากคุณต้องพัฒนาวิธีการบริการมากเกินไปเพื่อจัดการกับความเป็นไปได้ที่คุณต้องการในมุมมองนี้คุณก็กำลัง 'สร้างมลพิษ' ให้กับชั้นบริการด้วยเช่นกัน ไม่?

— HeDinges

1

ข้อแตกต่างประการหนึ่งคือการปิดเซสชันไฮเบอร์เนตล่าช้า คุณจะรอให้ JSP แสดงผล / เขียน / ฯลฯ และทำให้วัตถุอยู่ในหน่วยความจำนานขึ้น นั่นอาจเป็นปัญหาโดยเฉพาะอย่างยิ่งหากคุณต้องการเขียนข้อมูลในการคอมมิตเซสชัน

— Robert Munteanu

8

มันไม่สมเหตุสมผลที่จะบอกว่า OSIV ทำร้ายประสิทธิภาพ มีทางเลือกใดบ้างนอกจากการใช้ DTO ในกรณีนี้คุณจะมีประสิทธิภาพต่ำกว่าเสมอเนื่องจากข้อมูลที่ใช้โดยมุมมองใด ๆ จะต้องโหลดแม้ในมุมมองที่ไม่ต้องการก็ตาม

— Johannes Brodwall

11

ฉันคิดว่ามลพิษทำงานในทางกลับกัน ถ้าฉันต้องการโหลดข้อมูลอย่างกระตือรือร้นชั้นตรรกะ (หรือชั้นการเข้าถึงข้อมูลที่แย่กว่านั้น) จำเป็นต้องรู้ว่าวัตถุจะแสดงในลักษณะใด เปลี่ยนมุมมองและคุณจะโหลดสิ่งที่คุณไม่ต้องการหรือไม่มีวัตถุที่คุณต้องการ ข้อยกเว้นไฮเบอร์เนตเป็นข้อบกพร่องและเป็นพิษเช่นเดียวกับข้อยกเว้นอื่น ๆ ที่ไม่คาดคิด แต่ประสิทธิภาพเป็นปัญหา ปัญหาด้านประสิทธิภาพและความสามารถในการปรับขนาดจะบังคับให้คุณใช้ความคิดและทำงานในชั้นการเข้าถึงข้อมูลของคุณมากขึ้นและอาจบังคับให้ปิดเซสชันก่อนหน้านี้

— Jens Schauder

1

@JensSchauder "เปลี่ยนมุมมองแล้วคุณจะโหลดสิ่งที่คุณไม่ต้องการหรือไม่มีวัตถุที่คุณต้องการ" ตรงนี้แหละครับ หากคุณเปลี่ยนมุมมองจะเป็นการดีกว่ามากถ้าจะโหลดสิ่งที่คุณไม่ต้องการ (เนื่องจากคุณมีแนวโน้มที่จะดึงข้อมูลเหล่านั้นออกมา) หรือค้นหาวัตถุที่หายไปเนื่องจากคุณจะได้รับข้อยกเว้นในการโหลด Lazy แทนที่จะปล่อยให้มุมมองโหลด มันขี้เกียจเพราะจะส่งผลให้เกิดปัญหา N + 1 และคุณไม่รู้ด้วยซ้ำว่ามันกำลังเกิดขึ้น ดังนั้น IMO จึงเป็นชั้นบริการที่ดีกว่า (และคุณ) รู้ว่ามันถูกส่งออกไปอย่างไรมากกว่าการโหลดมุมมองอย่างเฉื่อยชาและคุณไม่รู้อะไรเลย

— Jeshurun

40

สำหรับคำอธิบายอีกต่อไปคุณสามารถอ่านของฉันเปิด Session ในมุมมองต่อต้านรูปแบบบทความ มิฉะนั้นนี่คือสรุปสาเหตุที่คุณไม่ควรใช้ Open Session In View

Open Session In View ใช้วิธีการที่ไม่ดีในการดึงข้อมูล แทนที่จะปล่อยให้ชั้นธุรกิจตัดสินใจว่าจะดึงการเชื่อมโยงทั้งหมดที่ต้องการโดยเลเยอร์ View ได้อย่างไร แต่จะบังคับให้ Persistence Context ยังคงเปิดอยู่เพื่อให้เลเยอร์ View สามารถทริกเกอร์การเริ่มต้น Proxy ได้

OpenSessionInViewFilterเรียกopenSessionวิธีการพื้นฐานและได้รับใหม่SessionFactorySession
ถูกผูกไว้กับSessionTransactionSynchronizationManager
การOpenSessionInViewFilterเรียกใช้doFilterการjavax.servlet.FilterChainอ้างอิงอ็อบเจ็กต์และคำร้องขอจะถูกประมวลผลเพิ่มเติม
DispatcherServletเรียกว่าและเส้นทางการร้องขอ HTTP PostControllerเพื่อพื้นฐาน
PostControllerเรียกPostServiceที่จะได้รับรายชื่อของPostหน่วยงาน
PostServiceเปิดรายการใหม่และHibernateTransactionManagerreuses เดียวกันที่ถูกเปิดออกโดยSessionOpenSessionInViewFilter
PostDAOเรียกรายชื่อของPostหน่วยงานโดยไม่ต้องเริ่มต้นการเชื่อมโยงใด ๆ ขี้เกียจ
PostServiceกระทำธุรกรรมพื้นฐาน แต่Sessionไม่ได้ปิดเพราะมันถูกเปิดออกภายนอก
การDispatcherServletเริ่มต้นการแสดงผล UI ซึ่งในทางกลับกันจะนำทางการเชื่อมโยงแบบ lazy และทริกเกอร์การเริ่มต้น
OpenSessionInViewFilterสามารถปิดSessionและเชื่อมต่อฐานข้อมูลพื้นฐานจะถูกปล่อยออกเช่นกัน

เมื่อมองแวบแรกสิ่งนี้อาจดูเหมือนไม่ใช่เรื่องน่ากลัวที่ต้องทำ แต่เมื่อคุณดูจากมุมมองของฐานข้อมูลข้อบกพร่องต่างๆจะเริ่มชัดเจนขึ้น

ชั้นบริการเปิดและปิดธุรกรรมฐานข้อมูล แต่หลังจากนั้นไม่มีธุรกรรมที่ชัดเจนเกิดขึ้น ด้วยเหตุนี้ทุกคำสั่งเพิ่มเติมที่ออกจากเฟสการเรนเดอร์ UI จะถูกดำเนินการในโหมดการคอมมิตอัตโนมัติ การคอมมิตอัตโนมัติจะสร้างแรงกดดันให้กับเซิร์ฟเวอร์ฐานข้อมูลเนื่องจากแต่ละคำสั่งต้องล้างบันทึกธุรกรรมลงในดิสก์ดังนั้นจึงทำให้มีการรับส่งข้อมูล I / O จำนวนมากที่ฝั่งฐานข้อมูล การเพิ่มประสิทธิภาพอย่างหนึ่งคือการทำเครื่องหมายConnectionว่าอ่านอย่างเดียวซึ่งจะช่วยให้เซิร์ฟเวอร์ฐานข้อมูลหลีกเลี่ยงการเขียนลงในบันทึกธุรกรรม

ไม่มีการแยกข้อกังวลอีกต่อไปเนื่องจากคำสั่งถูกสร้างขึ้นโดยชั้นบริการและโดยกระบวนการแสดงผล UI การเขียนการทดสอบการรวมที่ยืนยันจำนวนคำสั่งที่สร้างขึ้นจะต้องผ่านทุกเลเยอร์ (เว็บบริการ DAO) ในขณะที่มีการปรับใช้แอปพลิเคชันบนเว็บคอนเทนเนอร์ แม้ว่าจะใช้ฐานข้อมูลในหน่วยความจำ (เช่น HSQLDB) และเว็บเซิร์ฟเวอร์ที่มีน้ำหนักเบา (เช่น Jetty) การทดสอบการรวมเหล่านี้จะดำเนินการได้ช้ากว่าการแยกชั้นและการทดสอบการรวมส่วนหลังจะใช้ฐานข้อมูลในขณะที่ การทดสอบการรวมส่วนหน้ากำลังจำลองชั้นบริการโดยสิ้นเชิง

เลเยอร์ UI จำกัด เฉพาะการนำทางที่เชื่อมโยงซึ่งสามารถทำให้เกิดปัญหาการสืบค้น N + 1 ได้ในทางกลับกัน แม้ว่าไฮเบอร์เนตจะเสนอ@BatchSizeการดึงการเชื่อมโยงเป็นกลุ่มและFetchMode.SUBSELECTเพื่อรับมือกับสถานการณ์นี้ แต่คำอธิบายประกอบจะส่งผลต่อแผนการดึงข้อมูลเริ่มต้นดังนั้นจึงนำไปใช้กับทุกกรณีการใช้งานทางธุรกิจ ด้วยเหตุนี้แบบสอบถามชั้นการเข้าถึงข้อมูลจึงเหมาะสมกว่ามากเนื่องจากสามารถปรับแต่งให้เหมาะกับข้อกำหนดการดึงข้อมูลกรณีการใช้งานปัจจุบัน

สุดท้าย แต่ไม่ท้ายสุดการเชื่อมต่อฐานข้อมูลอาจถูกระงับตลอดระยะการแสดงผล UI (ขึ้นอยู่กับโหมดการปล่อยการเชื่อมต่อของคุณ) ซึ่งจะเพิ่มเวลาเช่าการเชื่อมต่อและ จำกัด ปริมาณงานธุรกรรมโดยรวมเนื่องจากความแออัดในพูลการเชื่อมต่อฐานข้อมูล ยิ่งมีการเชื่อมต่อมากขึ้นคำขออื่น ๆ ที่พร้อมกันจะต้องรอรับการเชื่อมต่อจากพูลมากขึ้น

ดังนั้นไม่ว่าคุณจะถูกระงับการเชื่อมต่อไว้นานเกินไปหรือคุณได้รับ / ปล่อยการเชื่อมต่อหลายรายการสำหรับคำขอ HTTP เดียวดังนั้นจึงกดดันพูลการเชื่อมต่อที่อยู่เบื้องหลังและ จำกัด ความสามารถในการปรับขยาย

สปริงบูต

แต่น่าเสียดายที่เปิดเซสชันในวิวถูกเปิดใช้งานโดยเริ่มต้นในฤดูใบไม้ผลิ Boot

ดังนั้นตรวจสอบให้แน่ใจว่าในapplication.propertiesไฟล์กำหนดค่าคุณมีรายการต่อไปนี้:

spring.jpa.open-in-view=false

นี้จะปิดการใช้งาน OSIV เพื่อให้คุณสามารถจัดการกับLazyInitializationExceptionวิธีการที่เหมาะสม

— วลาดมิฮาลเซีย
แหล่งที่มา

3

การใช้ Open Session ใน View พร้อมการคอมมิตอัตโนมัติเป็นไปได้ แต่ไม่ใช่วิธีที่นักพัฒนาไฮเบอร์เนตตั้งใจไว้ ดังนั้นแม้ว่า Open Session ใน View จะมีข้อเสีย แต่การคอมมิตอัตโนมัติก็ไม่ใช่เพราะคุณสามารถปิดและยังคงใช้งานได้

— stefan.m

คุณกำลังพูดถึงสิ่งที่เกิดขึ้นภายในธุรกรรมและนั่นคือความจริง แต่เฟสการแสดงผลของเลเยอร์เว็บเกิดขึ้นนอกไฮเบอร์เนตดังนั้นคุณจะได้รับโหมด autocommit มีเหตุผล?

— Vlad Mihalcea

ฉันคิดว่านั่นเป็นตัวแปรที่ไม่ใช่ตัวแปรที่ดีที่สุดสำหรับ Open Session in View เซสชันและธุรกรรมควรยังคงเปิดอยู่จนกว่าจะแสดงผลมุมมองจากนั้นจึงไม่จำเป็นต้องใช้โหมด autocommit

— stefan.m

2

เซสชันยังคงเปิดอยู่ แต่การทำธุรกรรมไม่ได้ การเว้นระยะการทำธุรกรรมในกระบวนการทั้งหมดนั้นไม่เหมาะสมเนื่องจากเป็นการเพิ่มความยาวและการล็อกจะนานเกินความจำเป็น ลองนึกภาพว่าจะเกิดอะไรขึ้นหากมุมมองส่ง RuntimeException ธุรกรรมจะย้อนกลับเนื่องจากการแสดง UI ล้มเหลวหรือไม่

— Vlad Mihalcea

ขอบคุณมากสำหรับคำตอบโดยละเอียด! ฉันจะเปลี่ยนคำแนะนำในตอนท้ายเนื่องจากผู้ใช้สปริงบูตน่าจะไม่ใช้ jpa ในลักษณะนั้น

— Skeeve

24

สามารถทำธุรกรรมได้ในชั้นบริการ - ธุรกรรมไม่เกี่ยวข้องกับ OSIV มันSessionยังคงเปิดอยู่ไม่ใช่ธุรกรรมกำลังทำงานอยู่
หากเลเยอร์แอปพลิเคชันของคุณกระจายอยู่ในหลาย ๆ เครื่องคุณก็ไม่สามารถใช้ OSIV ได้คุณต้องเริ่มต้นทุกสิ่งที่คุณต้องการก่อนที่จะส่งวัตถุผ่านสาย
OSIV เป็นวิธีที่ดีและโปร่งใส (กล่าวคือ - ไม่มีรหัสของคุณทราบว่าเกิดขึ้น) ในการใช้ประโยชน์จากประสิทธิภาพของการโหลดแบบขี้เกียจ

— Bozho
แหล่งที่มา

2

เกี่ยวกับสัญลักษณ์แสดงหัวข้อย่อยแรกอย่างน้อยก็ไม่เป็นความจริงสำหรับOSIVดั้งเดิมจากวิกิ JBoss มันยังจัดการการแบ่งเขตธุรกรรมรอบ ๆ คำขอ

— Pascal Thivent

@PascalThivent ส่วนไหนที่ทำให้คุณคิดอย่างนั้น?

— Sanghyun Lee

13

ฉันจะไม่บอกว่า Open Session In View ถือเป็นการปฏิบัติที่ไม่ดี อะไรทำให้คุณประทับใจขนาดนั้น?

Open-Session-In-View เป็นวิธีง่ายๆในการจัดการเซสชันด้วย Hibernate เพราะมันเรียบง่ายบางครั้งมันก็ง่าย หากคุณต้องการการควบคุมธุรกรรมของคุณอย่างละเอียดเช่นการมีธุรกรรมหลายรายการในคำขอ Open-Session-In-View ไม่ใช่แนวทางที่ดีเสมอไป

ดังที่คนอื่น ๆ ได้ชี้ให้เห็นว่ามีการแลกเปลี่ยนกับ OSIV - คุณมีแนวโน้มที่จะเกิดปัญหา N + 1 มากขึ้นเนื่องจากคุณมีโอกาสน้อยที่จะตระหนักว่าธุรกรรมใดที่คุณกำลังเริ่มต้น ในขณะเดียวกันก็หมายความว่าคุณไม่จำเป็นต้องเปลี่ยนชั้นบริการเพื่อปรับให้เข้ากับการเปลี่ยนแปลงเล็กน้อยในมุมมองของคุณ

— Geoffrey Wiseman
แหล่งที่มา

5

หากคุณกำลังใช้ผกผันของ Control (IOC) ภาชนะเช่นฤดูใบไม้ผลิคุณอาจต้องการที่จะอ่านขึ้นบนถั่วกำหนดขอบเขต โดยพื้นฐานแล้วฉันกำลังบอกให้ Spring ให้SessionวัตถุHibernate แก่ฉันซึ่งมีวงจรชีวิตครอบคลุมคำขอทั้งหมด (กล่าวคือสร้างและทำลายเมื่อเริ่มต้นและสิ้นสุดคำขอ HTTP) ฉันไม่ต้องกังวลเกี่ยวกับLazyLoadExceptions หรือปิดเซสชันเนื่องจากคอนเทนเนอร์ IoC จัดการให้ฉัน

ดังที่ได้กล่าวไว้คุณจะต้องคิดถึงปัญหาประสิทธิภาพ N + 1 SELECT คุณสามารถกำหนดค่าเอนทิตีไฮเบอร์เนตของคุณได้ตลอดเวลาหลังจากนั้นเพื่อทำการโหลดการเข้าร่วมอย่างกระตือรือร้นในสถานที่ที่ประสิทธิภาพเป็นปัญหา

โซลูชันการกำหนดขอบเขตถั่วไม่ใช่เฉพาะฤดูใบไม้ผลิ ฉันรู้ว่า PicoContainer มีความสามารถเดียวกันและฉันแน่ใจว่าคอนเทนเนอร์ IoC ที่เป็นผู้ใหญ่อื่น ๆ มีสิ่งที่คล้ายกัน

— 0sumgain
แหล่งที่มา

1

คุณมีตัวชี้ไปที่การใช้งานจริงของเซสชันไฮเบอร์เนตที่มีให้ใช้งานในมุมมองผ่านคำขอที่กำหนดขอบเขตหรือไม่?

— Marvo

4

จากประสบการณ์ของตัวเอง OSIV ไม่ได้แย่มาก ข้อตกลงเดียวที่ฉันทำคือใช้ธุรกรรมที่แตกต่างกันสองรายการ: - รายการแรกเปิดใน "ชั้นบริการ" โดยที่ฉันมี "ตรรกะทางธุรกิจ" - รายการที่สองเปิดก่อนการแสดงผลมุมมอง

— ดาวิเด้
แหล่งที่มา

3

ฉันเพิ่งโพสต์เกี่ยวกับหลักเกณฑ์บางประการเกี่ยวกับเวลาที่จะใช้เซสชันแบบเปิดในการดูในบล็อกของฉัน ตรวจสอบว่าคุณสนใจ

http://heapdump.wordpress.com/2010/04/04/should-i-use-open-session-in-view/

— คริสอัพตัน
แหล่งที่มา

1

ตามหลักการทั่วไปของ SO หากคุณกำลังให้คำตอบคุณควรทำมากกว่าเพียงแค่เชื่อมโยงไปที่อื่น บางทีอาจให้หนึ่งหรือสองประโยคหรือรายการที่ระบุไว้ให้ส่วนสำคัญ คุณสามารถเชื่อมโยงได้ แต่คุณต้องการให้มูลค่าเพิ่มเติมเล็กน้อย มิฉะนั้นคุณอาจต้องการเพียงแสดงความคิดเห็นและวางลิงก์ไว้ที่นั่น

— DWright

การเชื่อมโยงในคำตอบนี้เป็นมูลค่าการอ่านก็ให้คำแนะนำที่ดีในเมื่อจะใช้ OSIV และไม่ได้

— AMS

1

ฉันเป็น v. สนิมบนไฮเบอร์เนต .. แต่ฉันคิดว่าเป็นไปได้ที่จะมีธุรกรรมหลายรายการในเซสชันไฮเบอร์เนตเดียว ดังนั้นขอบเขตธุรกรรมของคุณจึงไม่จำเป็นต้องเหมือนกับเหตุการณ์เริ่มต้น / หยุดเซสชัน

OSIV, imo มีประโยชน์เป็นหลักเนื่องจากเราสามารถหลีกเลี่ยงการเขียนโค้ดสำหรับการเริ่มต้น 'บริบทการคงอยู่' (หรือที่เรียกว่าเซสชัน) ทุกครั้งที่คำขอต้องการเข้าถึงฐานข้อมูล

ในชั้นบริการของคุณคุณอาจต้องโทรไปยังวิธีการที่มีความต้องการในการทำธุรกรรมที่แตกต่างกันเช่น 'จำเป็นต้องมีใหม่เป็นต้น' สิ่งเดียวที่วิธีการเหล่านี้ต้องการก็คือมีใครบางคน (เช่นตัวกรอง OSIV) เริ่มต้นบริบทการคงอยู่ดังนั้นสิ่งเดียวที่พวกเขาต้องกังวลคือ - "เดี๋ยวก่อนให้ฉันช่วงจำศีลสำหรับเธรดนี้ .. ฉันต้องทำบางอย่าง DB stuff ".

— rjk2008
แหล่งที่มา

1

สิ่งนี้จะไม่ช่วยมากนัก แต่คุณสามารถตรวจสอบหัวข้อของฉันได้ที่นี่: * Hibernate Cache1 OutOfMemory ด้วย OpenSessionInView

ฉันมีปัญหา OutOfMemory บางอย่างเนื่องจาก OpenSessionInView และเอนทิตีจำนวนมากโหลดเนื่องจากอยู่ใน Hibernate cache level1 และไม่ได้รวบรวมขยะ (ฉันโหลดเอนทิตีจำนวนมากโดยมี 500 รายการต่อหน้า แต่เอนทิตีทั้งหมดยังคงอยู่ในแคช)

— Sebastien Lorber
แหล่งที่มา