1_Transaction Overview

การออกแบบและจัดการทรานแซกชั่นไม่ใช่เรื่องง่าย แต่ก็ไม่ได้ยากจนเกินไป ขอเล่าพื้นฐานและหลักการคร่าวๆ ที่เกี่ยวข้องกับการออกแบบและจัดการทรานแซกชั่นกันครับ เหมือนเป็นการทบทวนไปในตัว ก่อนที่เราจะเข้าสู่การวิเคราะห์และออกแบบทรานแซกชั่นต่อไปกัน

Transaction & Transaction Processing

Transaction หรือในภาษาไทยคือคำว่า ‘ธุรกรรม’ หมายถึง กิจกรรมที่เกี่ยวกับการทำนิติกรรม สัญญา หรือการดำเนินการใดๆ ที่เกี่ยวข้อง หรือที่มักเข้าใจกันโดยทั่วไป คือ กิจกรรมที่มีการซื้อขายแลกเปลี่ยนกันเกิดขึ้น

ในทางไอทีอาจอธิบายได้ว่า คือ กิจกรรมที่มีการประมวลผลและใช้ทรัพยากรประกอบการประมวลผล โดยมุ่งเน้นถึงผลลัพธ์ที่ผูกพันกับข้อมูลเข้า(อินพุต) และความรับผิดชอบของกิจกรรม ผลลัพธ์ของทรานแซกชั่นอยู่บนพื้นฐานแบบ ‘all-or-nothing’

Transaction Processing คือ การประมวลผลข้อมูล โดยแบ่งเป็นส่วนๆ แบ่งเป็น operation ย่อยๆ ซึ่งเรียกว่า ‘transaction’ โดย:

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

Event Source & Arrival Event

Event Source คือ สิ่งที่สร้างเหตุการณ์ (event) ขึ้นทำให้เกิดการใช้ resource ตามมา เช่น เมื่อเกิดการประมวลผลก็จะเกิดการใช้ resource ในการออกแบบเราต้องวิเคราะห์ตั้งแต่จุดที่ request จากไคลเอนต์มาถึงระบบ หรืออย่างน้อยมาถึงจุดที่ทำให้เกิดการ begin ทรานแซกชั่น

Arrival Event คือ การเกิดขึ้นของเหตุการณ์ ซึ่งจำเป็นต้องทราบว่ามีความถี่เท่าไหร่เป็นประเภทไหน จะได้นำไปวิเคราะห์และคาดการณ์ได้ โดยแบ่งเป็นประเภทเหตุการณ์ คือ

Event source ชนิดต่างๆ

  • Periodic event เช่น ทุกสิ้นเดือนระบบฝาก/ถอนของธนาคารจะทำงานหนัก, พนักงานแผนกบัญชีมักล็อกอินเข้าระบบในช่วง 8:00-8:15 ของทุกวัน, ทุก 15 วินาที มีการ backup transaction state ตลอดทั้งวัน, ลูกค้าประเภท B เมื่อกดรหัสบัตร ATM เสร็จแล้วจะถอนเงินด้วยการเลือกตัวเลขบนหน้าจอทันที, ระบบยื่นแบบภาษีออนไลน์มักทำงานหนักในสัปดาห์สุดท้าย
  • Sporadic event เช่น admin ของระบบมักเข้ามาตรวจสอบสถานะการทำงานในช่วง 7:00-8:00 กับ 17:00-18:00 นอกเหนือเวลานี้จะเข้ามาเป็นครั้งคราว หรือขึ้นกับสถานการณ์, ลูกค้าประเภท Z มักเข้ามาซื้อสินค้าผ่านเว็บในช่วงกลางคืน แต่ช่วงเช้าและกลางวันก็มีเข้ามาบ้าง, เมื่อมีการอัพเดตโปรโมชั่นใหม่ ลูกค้ามักเข้ามาสั่งซื้อสินค้ามากขึ้นในช่วง 3 วันแรก แต่บางโปรโมชั่นก็ไม่ประสบความสำเร็จ
  • Stochastic event เช่น เจ้าหน้าที่ไม่ทราบว่าลูกค้าที่เข้าใช้ระบบ internet banking แต่ละคน เมื่อล็อกอินผ่านแล้วจะทำอะไรต่อไป, ทีมงานไม่ทราบได้ว่า request ที่ส่งมาจากจุดจำหน่ายบัตรคอนเสิร์ต 8,500 สาขาทั่วประเทศ จะค้นหาสถานะที่นั่งในรอบใดราคาใด, ราคาหุ้นหลายตัวที่ถูกปั่นราคาจนมีราคาสูงขึ้นและลดลงอย่างรวดเร็วได้ทำให้ตลาดหลักทรัพย์มีความผันผวนหนักซึ่งกระทำโดยนักปั่นราคาที่มีทุนมหาศาลทำตัวเสมือนเจ้ามือในวงพนัน

Stochastic event นั้นน่ากลัวที่สุด เพราะคาดการณ์ไม่ได้ หากอยากคาดการณ์ได้ก็ต้องการสำรวจวิจัย และวิเคราะห์เชิงสถิติ ส่วน Periordic event นั้นน่ากลัวน้อยสุด เพราะคาดการณ์ได้ จะได้สำรองทรัพยากรได้ง่ายกว่า

ประเด็นเรื่อง Event source และ arrival event มีผลต่อ performance ในการประมวลผลทรานแซกชั่นมาก สมมติฐานคือ ถ้าระบบอยู่เฉยๆ ก็ไม่มีการประมวลผล ไม่มีการใช้ทรัพยากร ดังนั้นระบบจะประมวลผลก็เมื่อมี request มาเข้านั่นเอง ดังนั้นเราจึงต้องทราบรูปแบบของ request ที่เข้ามาให้ได้

ACID

ACID คือ คุณสมบัติของการจัดการ transaction ในการเข้าถึง resource เพื่อให้การทำงานมีความน่าเชื่อถือและมีประสิทธิภาพ

  • A – Atomicity คือ หน่วย (atom) ของ transaction โดย transaction ควรแบ่งเป็น atom หรือ transaction เล็กๆ ย่อยๆ ซึ่งแต่ละ atom มีการจัดการ transaction เป็นของตัวเอง หรือขึ้นกับการจัดการ ผลลัพธ์คือสำเร็จทั้งหมดหรือไม่ก็ rollback ทั้งหมด
  • C – Consistency คือ การจัดการความน่าเชื่อถือ ความถูกต้อง และความสอดคล้องของ resource เมื่อเกิดเหตุการณ์ที่มีหลายงานเข้าถึง resource เดียวกันพร้อมๆ กัน
  • I – Isolation คือ การป้องกันการผิดพลาดจากการเข้าถึง resource พร้อมๆ กัน เป็นลักษณะของการจัดการด้านการ lock resource และเพื่อป้องกันการการเกิด dead-lock
  • D – Durability คือ ระยะเวลาของ atom หรือ transaction ที่ประมวลผล สังเกตุได้ว่าหาก atom มีขนาดใหญ่จะส่งผลต่อระยะเวลาที่นานขึ้น

 

ประเภทของ transaction

หากแบ่งตามประเภทการประมวลผล เช่น Local transaction processing, Distributed transaction processing

หากแบ่งตามประเภทโมเดลของทรานแซกชั่นตาม Transaction Service Specification โดย OMG (Object Management Group) เช่น Flat transaction, Nested transaction

หากแบ่งตามประเภทโมเดลของทรานแซกชั่นตามแนวทางของภาษาโปรแกรมนั้นๆ เช่นใน Java แบ่งเป็น Local transaction model, Programmatic transaction model, Declarative transaction model

หรือใช้วิธีวาดรูป transaction model หลังจากวิเคราะห์ความต้องการประเภทต่างๆ และวิเคราะห์ปัจจัยต่างๆ แล้ววิเคราะห์รูปโมเดลต่างๆ แล้วจำแนกว่าในระบบที่กำลังพัฒนานี้น่าจะแบ่งทรานแซกชั่นออกเป็นกี่ประเภท กี่กลุ่ม เช่น แบ่งตามระดับขนาด(สั้น-ยาว), ระดับความซับซ้อน, ความถี่ในการเข้าใช้ resource และ shared resource, ปริมาณ resource system ที่เข้าใช้ ฯลฯ

ตัวอย่าง – ทรานแซกชั่นในรูปแบบซอร์สโค้ดในภาษา Java

ตัวอย่างโค้ดทรานแซกชั่นในภาษา Java

Operation สำหรับการจัดการ transaction หลักๆ

Begin คือ การเริ่มต้นทรานแซกชั่น และเป็นการแจ้งให้ transaction manager รับรู้และพร้อมจัดการ เป็นการเริ่มต้น (สร้าง) unit of work พร้อมกับสร้าง transaction session เริ่มจองหน่วยความจำ เพื่อเตรียมเก็บ transaction data หรือ temporary data

Commit คือ การจบหรือปิดทรานแซกชั่น เมื่อประมวลผลทรานแซกชั่นเสร็จ

Rollback คือ การย้อนสถานะของ transaction data กลับไปสู่จุดเริ่มต้น หรือจุดที่ได้มาร์ก check point ไว้

Continue คือ การตัดสินใจทำทรานแซกชั่นต่อ โดยไม่ rollback หรือ rollback เฉพาะบางจุดที่กำหนด ในกรณีที่อาจเกิด error ขึ้น

Get Status คือ การแจ้งสถานะของทรานแซกชั่น เช่น active, committed, committing, marked rollback, no transaction, prepared, preparing, rolled back, rolling back, unknown

องค์ประกอบหลักในการจัดการทรานแซกชั่นตาม Transaction Service Specification โดย OMG

Transaction service โดย OMG

Transaction Status

เราสามารถทราบสถานะของทรานแซกชั่นได้ด้วยการเขียนโปรแกรมเรียกใช้ API ที่มี (ตรวจสอบภาษาโปรแกรม/เฟรมเวิร์ก/ไลบรารี่ ที่ใช้ ซึ่งปกติมีให้เรียกใช้ได้อยู่แล้ว) หรือดูจากซอฟต์แวร์ประเภท transaction process monitoring

ตัวอย่างสถานะทั่วไปของทรานแซกชั่น:

  • Active คือ ทรานแซกชั่นกำลังประมวลผลอยู่
  • Committed คือ ทรานแซกชั่น commit เสร็จแล้ว
  • Committing คือ ทราบแซกชั่นที่กำลัง commit แต่ยังไม่เสร็จ
  • Marked rollback คือ ทรานแซกชั่นถูกระบุว่าจะถูก rollback
  • No transaction คือ ไม่มีการสร้างทรานแซกชั่นเซสชั่น
  • Prepared คือ ทรานแซกชั่นเตรียมเสร็จแล้ว สิ่งที่ต้องเตรียม เช่น ทรานแซกชั่นเซสชั่น การเชื่อมต่อกับ transaction manager ฯลฯ
  • Preparing คือ ทรานแซกชั่นกำลังเตรียมพร้อม
  • Rolled back คือ ทรานแซกชั่นถูก rollback แล้ว
  • Rolling back คือ ทรานแซกชั่นกำลัง rollback
  • Unknown คือ ไม่ทราบสถานะของทรานแซกชั่น

 

Granularity

Granularity เน้นในด้านขนาดของสิ่งต่างๆ เป็นหน่วยๆ และยังเกี่ยวข้องกับปริมาณของสิ่งนั้นๆ Granularity มีผลต่อ performance มาก

Granularity

 

Life Cycle – วัฏจักรสิ่งใดๆ โดยทั่วไปคือการสร้าง (construct), การถูกใช้ (action / use), การทำลาย (destroy) อาจมึขั้นตอนเพิ่มเติมอื่น เช่น pre-condition หรือ initialization

Impact – ขนาดของสิ่งใดๆ มีผลต่อเนื้อที่หรือพื้นที่, การคงอยู่ของสิ่งนั้นสั้น-ยาวมีผลต่อระยะเวลาและการถือครองเนื้อที่หรือพื้นที่

State – สิ่งใดๆ อาจมีการเปลี่ยนแปลงสถานะ หรือเคลื่อนที่ได้ เช่น

  • swap-out จากสถานะ ready ในหน่วยความจำสู่สถานะ block ในฮาร์ดดิสก์
  • swap-in จากสถานะ block ในฮาร์ดดิสก์สู่สถานะ running ในหน่วยความจำ

Granularity ใช้ได้กับ เช่น Object Granularity, Data Granularity, Parameter Granularity, Service Granularity

Size – ขนาดของสิ่งใดๆ จะทราบได้ต้องมีตัวเปรียบเทียบ สิ่งที่มีขนาดเล็กๆ เรียกว่า Fine-Grain เช่น fine-grained object สิ่งที่มีขนาดใหญ่ๆ เรียกว่า Coarse-Grain เช่น coarse-grained object

Granularity2

State Transition & State Management Overview

State หรือ สภาวะภายใน ณ ช่วงเวลาขณะหนึ่งของ ‘สิ่งๆ หนึ่ง’ มีองค์ประกอบหลัก เช่น ข้อมูล, storage, เวลา, action, event, transition, lifecycle เป็นต้น นอกจากนี้อาจมี Worker, Business Rule/Logic ประกอบด้วยได้

สิ่งใดๆ โดยทั่วไปประกอบด้วย capability และ property ทั้ง capability และ property สามารถมี state ได้

  • State ของ capability คือ สภาวะของแต่ละขั้นตอนการทำงาน หรือการเปลี่ยนแปลงขณะประมวลผล
  • State ของ property คือ สภาวะของคุณสมบัติของสิ่งนั้นๆ

State Transition คือ การเปลี่ยนจากสถานะหนึ่งไปอีกสถานะหนึ่ง

  • เกิดขึ้นแบบ automatic
  • เกิดขึ้นแบบ manual หรือมี stimulus ไปกระทำ

 

ตัวอย่าง State Transition Table ของหน้าจอการสั่งซื้อสินค้า

ตัวอย่าง state transition table

  • S1 = หน้าใดๆ ที่มีปุ่ม ‘Check Out’
  • S2 = แสดงหน้าจอสรุปรายการสินค้าใน Shopping Cart
  • S3 = แสดงหน้าจอยืนยันการยกเลิกการสั่งซื้อ
  • S4 = แสดงหน้าจอให้ป้อนชื่อ ที่อยู่ และข้อมูลบัตรเครดิต
  • S5 = แสดงหน้าจอสรุปเสร็จสิ้นการสั่งซื้อ

 

State Management คือ การจัดการกับสภาวะของสิ่งนั้นๆ เช่น อ็อบเจ็คต์, session, temporary data ฯลฯ State ของสิ่งใดๆ มักต้องมีที่อยู่ (storage) ปกติมักคือหน่วยความจำ State จึงมี lifecycle และจำเป็นต้องมีการจัดการ เพื่อใช้หน่วยความจำหรือ storage ให้คุ้มค่า ไม่เปลือง

  • Swap-In / Activation / Object De-Serialization คือ การโหลด state กลับสู่หน่วยความจำ
  • Swap-Out / Passivation / Object Serialization คือ การโหลด state เก็บลง persistent storage เช่น ฮาร์ดดิสก์, database

ตัวอย่าง state transition

 

State Management จึงมักจำเป็นต้องสร้าง State Machine เป็นกลไกเพื่อทำหน้าที่นี้

ตัวอย่าง database connection pooling

ตัวอย่างการจัดสรรหน่วยความจำ

ปกติเมื่อทรานแซกชั่นเริ่มทำงาน (เมื่อ begin หรือ prepare) กลไกการจัดการทรานแซกชั่น หรือ transaction manager จะสร้าง session ขึ้นมาเรียกว่า transaction session หรือ transaction context เพื่อเก็บสถานะการทำงานและรายละเอียดของทรานแซกชั่นนั้นๆ ดังนั้นหากทรานแซกชั่นมีขนาดใหญ่และใช้เวลาประมวลผลนานกว่าจะเสร็จ ก็จะกินเนื้อที่ในหน่วยความจำมากและนาน ส่งผลเสียต่อ performance การออกแบบทรานแซกชั่นที่ดีคือ ควรทำให้ทรานแซกชั่นมีขนาดที่สุดเท่าที่จะทำได้ และประมวลผลให้เสร็จเร็วที่สุดเท่าที่จะทำได้ และยิ่งทรานแซกชั่นมีการเปลี่ยน state มากเท่าไรก็ยิ่งส่งผลเสียต่อ performance เพราะต้องคอยเก็บ state ซึ่งโดยปกติจะสร้าง state ใหม่ ไม่ write ทับ state เดิม เพื่อประโยชน์ในการ rollback/undo ได้ ยกเว้นการออกแบบและจัดการบางกรณีที่ให้ write ทับ state เดิมเลย ซึ่งจะไม่สามารถ rollback/undo หรือดู state ย้อนหลังได้

Transaction Propagation

Transaction Propagation คือ การส่งต่อการจัดการทรานแซกชั่นจากต้นทางไปยังปลายทาง หรือจาก caller method ไปยัง calling method เพื่อเชื่อมโยงการจัดการทรานแซกชั่น การส่งต่ออาจเป็นแบบ explicit propagate (โดยการเพิ่มพารามิเตอร์) หรือ implicit propagate (ไม่ต้องเพิ่มพารามิเตอร์)

ตัวอย่าง TX 1 ใช้ transaction attribute ‘Required’ และ TX 2 ใช้ ‘Requires New’

ตัวอย่าง transaction propagation

Unit of Work, Transaction, Nested Transaction

ทรานแซกชั่นหนึ่งสามารถประกอบด้วยทรานแซกชั่นย่อยๆ  ได้ หนึ่งหน่วย (atom) หรือหนึ่งบล็อกของทรานแซกชั่นคือ เริ่มจากตำแหน่ง begin จนถึง commit

NestedTX

ในหนึ่งหน่วยหรือหนึ่งทรานแซกชั่นก็คือ หนึ่ง unit of work หนึ่ง unit of work สามารถสัมพันธ์กับ operation เช่น create, update, delete, read, read only โดยต้องระบุ operation ที่เกี่ยวข้องให้ชัดเจน และองค์ประกอบอื่น เช่น Registered user, Registered date/time, Commit, Rollback

การประมวลผลทรานแซกชั่นก็คือ ทำทีละ unit of work หากเกิดข้อผิดพลาดก็ rollback ทีละ unit of work แต่ละ unit of work จัดเก็บอยู่ในโครงสร้างข้อมูลแบบ stack (ในทางปฏิบัติหรือระบบจัดการจริงอาจไม่ใช้ stack ก็ได้ แต่ประยุกต์อัลกอริธึมแบบ stack คือ ล่าสุดออกก่อน) แต่ละ unit of work ก็คือทรานแซกชั่นเซสชั่นนั่นเอง

Simultaneous Access

Simultaneous access คือ การเข้าถึง resource เดียวกันพร้อมกันจากหลายทรานแซกชั่น ทำให้เกิดการช่วงชิงกันเข้าใช้ resource หรือเรียกว่า resource contention ทำให้ต้องมีการตัดสินว่าใครจะได้เข้าใช้ resource หรือเรียกว่า resource arbitration การเข้าถึง resource เดียวกันพร้อมกันคราวละมากกว่า 1 ทรานแซกชั่นสามารถทำได้! การจัดการสลับหรือเข้าจังหวะเพื่อเข้าใช้ resource เรียกว่า synchronization

หากต้องการจัดการการช่วงชิงกันเข้าใช้ resource และต้องการจัดการความสอดคล้องและความถูกต้องของข้อมูล จึงต้องล็อก (lock) ข้อมูลเพื่อป้องกันความผิดพลาด โดยการล็อกมีหลายระดับ และมีหลายประเภท เช่น

  • จำแนกตาม Architectural Pattern:
    • Optimistic Offline Lock คือ การล็อกแบบในแง่ดี – ใครยืนยันทรานแซกชั่นหรือส่ง commit ก่อนได้ล็อกข้อมูล, การล็อกเกิดขึ้นเมื่อ confirm request จากใครก็ตามมาถึงขณะที่ตอนใช้ resource เดียวกันกันโดยหลายทรานแซกชั่นจะยังไม่มีการล็อกเกิดขึ้น
    • Pessimistic Offline Lock คือ การล็อกแบบในแง่ร้าย – ใครล็อกข้อมูลก่อนได้ commit, การล็อกเกิดขึ้นเมื่อทรานแซกชั่นแรกที่เข้าถึงข้อมูลก่อนเพื่อต้องการอัพเดต
    • Coarse-Grained Lock คือ การล็อกข้อมูลเป็นกลุ่ม
  • จำแนกตาม Isolation Level

IsolationLevel

 

ตัวอย่างการเซ็ต Isolation Lock ใน java.sql.Connection ในภาษา Java

IsolationLevel_Java

IsolationLevel_Java2

ในกลไกการจัดการทรานแซกชั่นหรือภาษาโปรแกรมหรือไดรเวอร์โดยทั่วไป มักใช้ default isolation คือ Repeatable Read บางตัวก็ใช้ Read Committed ตัวที่เกิดโอเวอร์เฮดสูงสุดแต่ชัวร์สุดคือ Serializable เพราะเข้าใช้คนเดียวเลย ซึ่งอาจทำให้เกิดคอขวดได้สูงมาก ส่วนตัวที่อันตรายที่สุดคือ Read Uncommitted แต่ถึงอันตรายก็ไม่ได้หมายความว่าไม่ควรใช้ เพราะจะใช้ isolation level แบบไหนนั้นขึ้นกับลักษณะงาน และควรออกแบบและเลือกให้สอดคล้องกัน business process กับ business rule

Scheduling Strategies for Resource Arbitration

การประมวลผลหลายงานพร้อมๆ กันเกิดขึ้นเร็วมาก เพราะซีพียูประมวลผลรวดเร็วมาก ซึ่งเป็นการใช้การเข้าจังหวะ (synchronization) ในลักษณะการสลับกันเข้า-ออก

  • เอางานเข้ามาใช้ทรัพยากร (swap-in)
  • เอางานออกจากการใช้ทรัพยากร (swap-out)
  • เลือกเอางานใหม่ที่จะเอาเข้ามาใช้ทรัพยากร (scheduling)

การ swap-in และ swap-out เป็นการใช้ I/O ยิ่งมีการสลับถี่ยิ่งใช้ I/O สูง Synchronization จึงเป็นการเข้าจังหวะของ swap-in, swap-out และ scheduling ให้เหมาะสมลงตัว มิฉะนั้นอาจเกิดการชนกัน หรือการแย่งกันหรือเกี่ยงกันเข้า ซึ่งอาจนำไปสู่การเกิด dead-lock โดยปกติจะไม่มีการให้ตั้งแต่ 2 งานขึ้นไปเข้าถึงทรัพยากรเดียวกันพร้อมกันได้

Scheduling Strategies หรือ Scheduling Algorithms เช่น First-In / First-Out หรือ Queue, Last-In / Last-Out หรือ Stack, Least Recently Use, Most Frequently Use, Semaphore, Round-Robin ฯลฯ

Transaction Orchestration

Transaction orchestration คือ การควบคุมลำดับหรือ flow ของทรานแซกชั่นในการทำงานแต่ละขั้นตอน มักใช้ Transaction Script Pattern [PoEAA] ในการจัดการ ซึ่งเป็นเสมือนเลเยอร์บางๆ ใน architecture ทำหน้าที่ควบคุมทรานแซกชั่น บางที่เรียกว่า Transaction Orchestrator ซึ่งสิ่งสำคัญคือไม่ควรให้เข้าถึง resource เองโดยตรง! เทคนิคนี้เป็นการออกแบบในแนว functional design ไม่ใช่ OO design เพราะการจัดการทรานแซกชั่นบางครั้งก็ต้องการ performance มากๆ ซึ่ง OO มี performance ที่แย่ เพราะ OO เน้น modifiability, reusability มากกว่าเน้น performance ดังนั้นในบางจุดของระบบเราต้องตัดสินใจว่าจะใช้ design principle แบบไหน จะใช้แบบเดียวทั้งระบบก็ได้ หรือบางจุดใช้แบบ functional บางจุดใช้แบบ OO ดังนั้นจึงควรใช้ให้เหมาะสม ข้อผิดพลาดที่พบได้บ่อยครั้งโดยเฉพาะกับทีมที่ใช้ OO และภาษาโปรแกรมแบบ OO คือมักใช้แนวคิดการออกแบบและเขียนโปรแกรมแบบ OO ทั้งระบบ ซึ่งไม่จำเป็นครับ ต้องเลือกให้เหมาะสมดีที่สุด ตรงไหนเน้น OO มาก ตรงไหนเน้น OO น้อย ตรงไหนใช้แนว functional ไปเลย เช่น ในระบบขนาดใหญ่อย่าง enterprise system ในจุดที่มีการทำ transaction orchestration หนักๆ จึงควรใช้แนว functional ผสม OO

TXOrchestration

Local & Distributed Transaction Processing

Local Transaction Processing คือ การจัดการทรานแซกชั่นโดย resource system ที่เข้าใช้

Distributed Transaction Processing คือ การจัดการทรานแซกชั่น ซึ่งในแต่ละขั้นตอนอาจประกอบด้วยทรานแซกชั่นย่อย หรือ operation ที่ต้องเข้าใช้ resource system ที่แตกต่างกัน ทำให้ทรานแซกชั่นใหญ่ที่อยู่นอกสุดต้องจัดการและควบคุมการประมวลผลทรานแซกชั่นใน resource system ต่างๆ ในอีกนัยหนึ่งก็คือ ทรานแซกชั่นที่ประกอบด้วย local transaction processing หลายส่วนที่กระจายไปยัง resource system ที่แตกต่างกัน โดยทรานแซกชั่นกลางที่อยู่นอกสุดต้องประสานงานเพื่อควบคุมความถูกต้องและความสอดคล้องของข้อมูลได้

Distributed Transaction Processing บางทีเรียกว่า Two Phase Commit โดย driver ที่ใช้เชื่อมต่อกับ resource system มักเรียกว่า Two Phase Commit Driver หรือ XA Driver

ตัวอย่าง Distributed Transaction Processing

DTM1

DTM2

DTM3

Transaction Model

Local Transaction Model คือ การจัดการทรานแซกชั่นเกิดขึ้นภายใน resource system ที่เข้าใช้ เช่น database server โดยไม่ได้จัดการที่ระดับแอพพลิเคชั่น หรือกล่าวอีกทางหนึ่งคือเป็นการจัดการที่ระดับ connection ที่เชื่อมต่อไปยัง resource system นั้นๆ เช่น

ตัวอย่างโค้ดทรานแซกชั่นในภาษา Java

Prgrammatic Transaction Model คือ การจัดการทรานแซกชั่นที่ระดับแอพพลิเคชั่น ด้วยการจัดการในระดับซอร์สโค้ดโดยนักพัฒนา ซึ่งเป็นการจัดการทรานแซกชั่นจริงๆ ไม่ใช่เน้นจัดการ connection ในแบบ local transaction model

ProgrammaticTXModel

Declarative Transaction Model คือ การจัดการทรานแซกชั่นแบบไม่ต้องเขียนโปรแกรมควบคุม ทำโดยการคอนฟิก หรือจัดการผ่านตัวกลาง

  • ข้อดี คือ ปรับเปลี่ยนรูปแบบการจัดการทรานแซกชั่นสะดวก ไม่ต้องแก้โค้ด
  • ข้อเสีย คือ
    • ต้องมีความเข้าใจการจัดการทรานแซกชั่นในแบบต่างๆ ที่ผ่านการคอนฟิก transaction attribute ซึ่งอาจมีความซับซ้อนมากได้
    • การจัดการขึ้นกับ Transaction API และ middleware ที่ใช้

Transaction Attribute เช่น

  • Required คือ ต้องประมวลผลภายใต้การจัดการทรานแซกชั่น, ถ้าไม่มีจะสร้างเอง
  • Not Required คือ ไม่ต้องการประมวลผลภายใต้การจัดการทรานแซกชั่น, ถ้ามีจะไม่สนใจ จะประมวลผลของตัวเอง โดยไม่มีการจัดการทรานแซกชั่น
  • Requires New คือ ต้องการประมวลผลภายใต้การจัดการทรานแซกชั่น โดยต้องการจัดการเอง, จะสร้างใหม่สำหรับของตัวเอง
  • Mandatory คือ ต้องการประมวลผลภายใต้การจัดการทรานแซกชั่นเสมอ, ถ้าไม่มีจะแจ้ง exception
  • Support คือ รองรับการประมวลผลภายใต้การจัดการทรานแซกชั่น, ถ้ามีอยู่แล้วก็จะไปใช้ด้วย
  • Not Support คือ ไม่รองรับการประมวลผลภายใต้การจัดการทรานแซกชั่น , ถ้ามีจะแจ้ง exception
  • Read Only คือ การอ่านข้อมูลอย่างเดียว ซึ่งช่วยประหยัดการจัดการทรานแซกชั่น

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s