Spring-Java Things Rollback Failure Processing เมื่อเร็ว ๆ นี้ฉันกำลังทำงานในโครงการและพบว่าโดยบังเอิญว่าชั้นเรียนกำลังโยนการดำเนินการย้อนกลับและข้อมูลถูกแทรกเข้าไปในฐานข้อมูลตามปกติดังนั้นฉันจึงตรวจสอบอย่างระมัดระวังและดูเหตุผลที่เฉพาะเจาะจง
ทุกอย่างยังคงเริ่มต้นด้วยข้อยกเว้นที่ตรวจสอบของ Java และข้อยกเว้นที่ไม่ได้ตรวจสอบ
ดังนั้นข้อยกเว้นประเภทการตรวจสอบคืออะไรและข้อยกเว้นประเภทที่ไม่ใช่การตรวจสอบคืออะไร?
มีสองคะแนนการตัดสินที่ง่ายที่สุด:
1. ข้อยกเว้นที่ไม่ได้ตรวจสอบที่สืบทอดมาจาก RuntimeException หรือข้อผิดพลาดในขณะที่ข้อยกเว้นการตรวจสอบที่สืบทอดมาจากข้อยกเว้น (แน่นอน RuntimeException เองก็เป็น subclass ของข้อยกเว้น)
2. ข้อยกเว้นที่ไม่ได้ตรวจสอบสามารถจับได้โดยไม่ถูกจับในขณะที่ข้อยกเว้นที่ตรวจสอบจะต้องดำเนินการด้วยการลอง ... Catch Conttential Block หรือส่งข้อยกเว้นไปยังวิธีการที่เหนือกว่าสำหรับการประมวลผล ในระยะสั้นรหัสจะต้องเขียนเพื่อประมวลผล
โครงสร้างข้อยกเว้นของ Java แสดงในรูปด้านล่าง ในหมู่พวกเขาข้อยกเว้นที่จะต้องจับข้อยกเว้นโดยตรงและได้รับการตรวจสอบข้อยกเว้น
ลองกลับมาดูรหัสของฉัน:
1. ชื่อวิธีการนำหน้าโดย
@Transactional
2. ไฟล์การกำหนดค่าสปริง ApplicationContext-xxx.xml ยังมีการกำหนดค่าที่เกี่ยวข้องสำหรับสปริงสิ่งต่างๆ
<bean id = "transactionManager"> <property name = "dataSource" ref = "dataSource"/> <property name = "RollBackonCommitFailure" value = "true"> </property> </ebean>
แต่ทำไมสิ่งที่ถูกส่งมาหลังจากลอง ... จับข้อยกเว้นการขว้างปาไม่ได้ย้อนกลับเมื่อมีการเรียกวิธีเลเยอร์บริการ?
หลังจากตรวจสอบเอกสารประกอบฤดูใบไม้ผลิที่เกี่ยวข้องฉันพบว่าการจัดการธุรกรรมการประกาศสปริงแบบดั้งเดิมดำเนินการย้อนกลับการทำธุรกรรมในข้อยกเว้นที่ไม่ได้ตรวจสอบและข้อยกเว้นรันไทม์โดยค่าเริ่มต้นในขณะที่ไม่มีการย้อนกลับของข้อยกเว้นที่ตรวจสอบ
ข้อยกเว้นที่โยนโดยลอง ... จับในรหัสเป็นข้อยกเว้นประเภทการตรวจสอบ เฟรมเวิร์กของฤดูใบไม้ผลิจะไม่ย้อนกลับไปตามค่าเริ่มต้น
ในการเขียนโปรแกรมสามารถหลีกเลี่ยงข้อยกเว้นที่ไม่ได้ตรวจสอบได้ในขณะที่ข้อยกเว้นที่ตรวจสอบจะต้องดำเนินการกับบล็อกคำสั่งลองหรือส่งไปยังวิธีที่เหนือกว่าเพื่อจัดการกับพวกเขา ในระยะสั้นรหัสจะต้องเขียนเพื่อประมวลผล
ดังนั้นข้อยกเว้นจะต้องติดอยู่ในบริการแล้วโยนข้อยกเว้นที่ไม่ได้ตรวจสอบอีกครั้งด้วยตนเองเพื่อให้การทำธุรกรรมมีผล ตัวอย่างเช่น:
ลอง {………} catch (Exception e) {………โยน BusinessException ใหม่ (e.getMessage ()); -แน่นอนว่าเรามีวิธีที่ง่ายกว่าในการแก้ปัญหานี้นั่นคือเปลี่ยนวิธีการย้อนกลับเริ่มต้นโดยพารามิเตอร์หมายเหตุประกอบ
Norollbackfor และ Rollbackfor ถูกกำหนดไว้ในคำอธิบายประกอบ @Transaction เพื่อระบุว่ามีข้อยกเว้นบางอย่างย้อนกลับมาหรือไม่
ใช้ตัวอย่าง:
@Transaction (norollbackfor = runtimeException.class)
@TransAction (ROLLBACKFOR = Exception.class)
ดังนั้นในคำถามข้างต้นคุณสามารถเพิ่มพารามิเตอร์การย้อนกลับ @TransAction โดยตรง (RollBackfor = Exception.class) ซึ่งเปลี่ยนวิธีการประมวลผลธุรกรรมเริ่มต้น
การเปิดเผย:
สิ่งนี้ต้องการให้เราสืบทอดข้อยกเว้นที่กำหนดเองจาก RuntimeException เมื่อปรับแต่งข้อยกเว้นดังนั้นเมื่อถูกโยนมันจะได้รับการจัดการอย่างถูกต้องโดยการประมวลผลธุรกรรมเริ่มต้นของฤดูใบไม้ผลิ
สรุป
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้เกี่ยวกับปัญหาความล้มเหลวของการย้อนกลับการทำธุรกรรม Java ฉันหวังว่ามันจะเป็นประโยชน์กับทุกคน เพื่อนที่สนใจสามารถอ้างถึงหัวข้ออื่น ๆ ที่เกี่ยวข้องในเว็บไซต์นี้ต่อไป หากมีข้อบกพร่องใด ๆ โปรดฝากข้อความไว้เพื่อชี้ให้เห็น ขอบคุณเพื่อนที่ให้การสนับสนุนเว็บไซต์นี้!