VPN тасрах үед өгөгдлийн сан хоорондын шилжүүлэг үхдэг бөгөөд «дахин ажиллуул» нь сэргээх төлөвлөгөө биш. Эх сурвалжаас олборлолт дууссан байж болно, зорилтот сан аль хэдийн commit хийсэн байж болно, эсвэл хариулт буцах замд зүгээр л алдагдсан байж болно. Эдгээр гурван төлөв өөр өөр арга хэмжээ шаарддаг бөгөөд зөвхөн «алдаа» мэддэг клиент тэдгээрийг ялгаж чадахгүй.

Шийдэл нь архитектурынх: ажиллуулалт бүрт бат бөх багц таних тэмдэг өгч, клиентийг таамаглахыг зөвшөөрөхийн оронд өгөгдлийн сангууд асуултад хариулахыг зөвшөөр.

Өгөгдлийн сан үнэндээ юуг баталгаажуулдаг

SQL Server болон Oracle хоёулаа гүйлгээний дотор атомт чанарыг өгдөг. Хоёрын хооронд атомт чанарыг аль нь ч өгдөггүй. Алдагдсан холболт өгөгдлийн саныг гэмтээхгүй бөгөөд гараар буцаахыг шаарддаггүй, учир нь сервер өөрийн гүйлгээг таныггүйгээр шийддэг. Хагардаг нь дуудагчийн үр дүнгийн талаарх мэдлэг юм.

Тусдаа commit гэдэг нь тусдаа commit. Хоёр холболтыг зөөдөг VPN хоёр commit-ыг нэг ажлын нэгжид нэгтгэдэггүй.

Та хэзээ ч сонсоогүй commit

Нэг доголдлын горим гэнэн дахин оролдлогын логикийг шийтгэдэг: сервер commit хийдэг, баталгаажуулалт дуудагчид хэзээ ч хүрдэггүй. Oracle үүнийг үл мэдэгдэх үр дүнгийн асуудал гэж баримтжуулж, үүнд зориулж гүйлгээний баримт бичигт Transaction Guard-ыг өгдөг. Харилцааны алдаа нь илгээсэн commit бүтэлгүйтсэн гэдгийн нотолгоо биш бөгөөд үүнийг нотолгоо гэж үзэх нь багцыг хоёр удаа нийтлэх зам юм. Энэ ялгаа нь дахин оролдлогын замд хамгийн чухал бөгөөд тэнд операторт алдааны мессеж байгаа бөгөөд ажиллах өөр дохио байхгүй.

Тиймээс сэргээх алхам нь үр дүнг алдааны текстээс дүгнэхийн оронд зорилтоос унших ёстой.

Шилжүүлэгт багцын таних тэмдэг өг

Ажиллуулалт бүр өөрчлөгдөхгүй багц ID авч, зорилтот сан тэр ID-ээр юу хийсэнээ бүртгэдэг. Амьдралын мөчлөг дөрвөн алхамтай бөгөөд нийлүүлэгчээс үл хамааран ижил харагдана:

  1. Олборлох бүртгэгдсэн схем, хил хязгаартай, тодорхойлогдсон, өөрчлөгдөхгүй эх багц.
  2. Шилжүүлэх үүнийг зорилтын бэлтгэл хэсэгт, бэлэн гэж зарлахаас өмнө дутуу эсвэл зөрчилтэй агуулгыг илрүүлэх.
  3. Хэрэглэх зорилтын өөрийн өвөрмөц эсвэл түгжих дүрмийн дагуу, дуусгасныг мөн адил орон нутгийн гүйлгээнд бүртгэх.
  4. Тохируулах бат бөх үр дүнг дэмжигдсэн протоколоор, баталгаажуулах эсвэл дахин оролдохоос өмнө.

Дахин оролдлогууд ижил ID-г дахин ашигладаг. Оролдлого бүрт шинэ ID нь дөнгөж барьсан давхардлын хамгаалалтыг эвддэг бөгөөд энэ нь дахин оролдлогын бүрхүүл автоматаар нэгийг үүсгэх хүртэл ойлгомжтой мэт санагддаг.

ID нь мөн клиентийн процесс аль эрт алга болсны дараа хожим тохируулах зүйлийг өгдөг.

Багцыг эзэмшиж, дараа нь хэрэглэ

Хэрэглэх алхам нь багцын ID-г эзэмших, бизнесийн өөрчлөлтийг хийх, дуусгасныг нэг орон нутгийн гүйлгээнд бүртгэх ёстой. Шалгалт, оруулгыг тусдаа тушаал болгон хийх нь таны зайлуулахыг оролдсон уралдааныг буцааж авчирдаг. Хоёр ажилчин өрсөлдвөл яг нэг эзэмшил ялж, нөгөөд нь мэдэгддэг.

Дуусгасны бүртгэл байхгүй байх нь үргэлжилж буй гүйлгээ хэзээ ч commit хийхгүй гэдгийн нотолгоо биш. Эзэмшил нь өрсөлдөж буй оролдлогуудыг цуварчлах ёстой, эсвэл протокол аливаа шийдвэр гаргахаас өмнө бат бөх үр дүнг унших ёстой.

Тэр цуварчлалд програмын код дахь шалга-дараа-давт давталтын оронд өгөгдлийн сангийн дэмжигдсэн механизмыг ашигла.

Дизайн хараахан амлаж чадахгүй зүйл

Бэлтгэл ажлыг дахин эхлүүлэх боломжтой болгож, нэг урт хугацааны сессээс хамааралтай байдлыг бууруулдаг. Энэ нь SQL Server, Oracle болон ажлын гүйцэтгэдэг аливаа гадаад гаж нөлөөний хэмжээнд нэг атомт commit үүсгэдэггүй. Хэрэв бизнес үүнийг үнэхээр шаарддаг бол дэмжигдсэн тархсан гүйлгээ эсвэл тохируулгын процессыг зохиож, мэргэжлийн түвшинд баталгаажуул, үүний дотор тодорхойгүй үр дүнтэй ажлыг хэн эзэмшихыг оруулан. Үүнээс сул зүйл нь шилжүүлгийн кодонд биш, тохируулгын гарын авлагад хамаарна.

Гурван газар тасалдлыг хүлээн зөвшөөр: шилжүүлгийн үеэр, хэрэглээний үеэр, мөн commit-ийн дараа боловч баталгаажуулалтын өмнө. Дараа нь клиентийн мессежийн оронд бизнесийн үр дүнг шалгаж, багцын дэвтэрт ажил дутуу, commit хийгдсэн эсвэл хараахан шийдэгдээгүй эсэхийг хэлүүлэх.

Холбоотой нийтлэлүүд