(1) Transaction T issues a read(x)(

(1) Transaction T issues a read(x)
(a) Transaction T asks to read an item (x) that has already been updated by a younger
(later) transaction, that is ts(T) < write_timestamp(x). This means that an earlier
transaction is trying to read a value of an item that has been updated by a later
transaction. The earlier transaction is too late to read the previous outdated value,
and any other values it has acquired are likely to be inconsistent with the updated
value of the data item. In this situation, transaction T must be aborted and
restarted with a new (later) timestamp.
(b) Otherwise, ts(T) ≥ write_timestamp(x), and the read operation can proceed. We
set read_timestamp(x) = max(ts(T), read_timestamp(x)).
(2) Transaction T issues a write( x)
(a) Transaction T asks to write an item ( x) whose value has already been read by a
younger transaction, that is ts(T) < read_timestamp( x). This means that a later trans-action is already using the current value of the item and it would be an error to
update it now. This occurs when a transaction is late in doing a write and a younger
transaction has already read the old value or written a new one. In this case, the
only solution is to roll back transaction T and restart it using a later timestamp.
(b) Transaction T asks to write an item ( x) whose value has already been written by a
younger transaction, that is ts(T) < write_timestamp(x). This means that trans-action T is attempting to write an obsolete value of data item x. Transaction T
should be rolled back and restarted using a later timestamp.
(c) Otherwise, the write operation can proceed. We set write_timestamp( x) = ts(T).
This scheme, called basic timestamp ordering, guarantees that transactions are conflict
serializable, and the results are equivalent to a serial schedule in which the transactions
are executed in chronological order of the timestamps. In other words, the results will be
as if all of transaction 1 were executed, then all of transaction 2, and so on, with no inter-leaving. However, basic timestamp ordering does not guarantee recoverable schedules.
Before we show how these rules can be used to generate a schedule using timestamping,
we first examine a slight variation to this protocol that provides greater concurrency.

ผลลัพธ์ (ไทย) 1:

(1) ธุรกรรม T ออก read(x)
(a) ธุรกรรม T ถามอ่านสินค้า (x) ที่มีการปรับปรุงธุรกรรม younger
(later) ที่ ts(T) < write_timestamp(x) นี้หมายความ ว่า มีก่อนหน้า
ธุรกรรมคือพยายามอ่านค่าของสินค้าที่มีการปรับปรุง โดยการต่อ
ธุรกรรม ธุรกรรมก่อนที่จะสายเกินไปอ่านค่าล้าสมัยก่อนหน้า,
และค่าอื่น ๆ ที่ได้มามักจะไม่สอดคล้องกับการปรับปรุง
ค่าของรายการข้อมูล ในสถานการณ์นี้ ธุรกรรม T ต้องยกเลิก และ
เริ่ม ด้วย timestamp.
(b) (หลัง) ใหม่จงระวัง ts(T) ≥ write_timestamp(x) และการอ่านสามารถดำเนินการได้ เรา
ตั้ง read_timestamp(x) = max(ts(T), read_timestamp(x)).
(2) T ธุรกรรมเรื่องการเขียน (x)
(ก) ธุรกรรม T ถามสินค้า (x) ค่าที่ได้อ่านโดยเขียนเป็น
ธุรกรรมอายุ ที่ ts(T) < read_timestamp (x) หมายความ ว่า ดำเนินธุรกรรมในภายหลังแล้วใช้ค่าปัจจุบันของสินค้า และจะมีข้อผิดพลาดการ
ปรับปรุงเดี๋ยวนี้ เกิดขึ้นเมื่อธุรกรรมเป็นสายในการทำการเขียนและการอายุ
ธุรกรรมได้แล้วอ่านค่าเดิม หรือเขียนใหม่ ในกรณีนี้
เพียงโซลูชันเพื่อ ย้อนกลับธุรกรรม T และเริ่มใช้ timestamp.
(b) ต่อธุรกรรม T ถามเขียนรายการ (x) ค่ามีการเขียนโดยการ
ธุรกรรมอายุ ที่ ts(T) < write_timestamp(x) หมายความ ว่า การดำเนินธุรกรรม T พยายามเขียนค่าล้าสมัยของสินค้าข้อมูล x ธุรกรรม T
ควรย้อนกลับมา และเริ่มใช้ timestamp.
(c) ภายหลังจงระวัง การเขียนสามารถดำเนินการ เราตั้ง write_timestamp (x) = ts (T) .
โครงร่างนี้ เรียกว่าพื้นฐานเวลาสั่งซื้อ รับประกันว่า ธุรกรรมมีความขัดแย้ง
อนุกรมได้ และผลเทียบเท่ากับตารางเวลาประจำที่ธุรกรรม
ในลำดับของการลงเวลา ในคำอื่น ๆ ผลลัพธ์จะ
ถ้าธุรกรรม 1 ทั้งหมดถูกดำเนินการ แล้วทั้งหมดของธุรกรรม 2 และอื่น ๆ โดยไม่ออกจากระหว่างการ อย่างไรก็ตาม สั่งพื้นฐานเวลารับประกันลูกหนี้กำหนดการ
ก่อนที่เราแสดงวิธีการใช้กฎเหล่านี้เพื่อสร้างกำหนดการใช้ระบุเวลา,
เราตรวจสอบก่อนการเปลี่ยนแปลงเล็กน้อยกับโพรโทคอลนี้ที่เกิดมากขึ้น

ผลลัพธ์ (ไทย) 2:

(1) การทำธุรกรรม T ปัญหาการอ่าน (x)
(ก) การทำธุรกรรม T ขอให้อ่านรายการ (x) ที่ได้รับการปรับปรุงแล้วโดยน้อง
write_timestamp (x) การทำธุรกรรม (ต่อมา) ซึ่งก็คือทีเอส (T) < ซึ่งหมายความว่าก่อนหน้านี้
การทำธุรกรรมที่มีการพยายามที่จะอ่านค่าของรายการที่ได้รับการปรับปรุงโดยภายหลัง
การทำธุรกรรม การทำธุรกรรมก่อนหน้านี้สายเกินไปที่จะอ่านค่าเก่าก่อนหน้านี้
และค่าอื่น ๆ ใด ๆ ที่ได้มามีแนวโน้มที่จะไม่สอดคล้องกับการปรับปรุง
ค่าของรายการข้อมูล ในสถานการณ์เช่นนี้การทำธุรกรรม T ต้องยกเลิกและ
เริ่มต้นใหม่กับใหม่ (ต่อ) เวลา
(ข) มิฉะนั้นทีเอส (T) ≥ write_timestamp (x) และการดำเนินการอ่านสามารถดำเนินการต่อ เรา
ตั้ง read_timestamp (x) = max (ทีเอส (T), read_timestamp (x))
(2) การทำธุรกรรม T ออกเขียน (x)
(ก) การทำธุรกรรม T ขอให้เขียนรายการ (x) ซึ่งมีค่าที่ได้รับการอ่านแล้ว โดย
การทำธุรกรรมที่มีอายุน้อยกว่าที่เป็นทีเอส (T) <read_timestamp (x) ซึ่งหมายความว่าต่อมาทรานส์แอ็กชันที่มีอยู่แล้วโดยใช้ค่าปัจจุบันของรายการและมันจะเป็นความผิดพลาดในการ
อัปเดตในขณะนี้ นี้เกิดขึ้นเมื่อการทำธุรกรรมที่จะสายในการทำและการเขียนที่มีอายุน้อยกว่า
การทำธุรกรรมที่มีอยู่แล้วอ่านค่าเก่าหรือเขียนใหม่ ในกรณีนี้
ทางออกเดียวคือการย้อนกลับรายการ T และเริ่มต้นใหม่ได้โดยใช้เวลาหลังจากนั้น
(ข) การทำธุรกรรม T ขอให้เขียนรายการ (x) ค่าที่มีได้รับการเขียนไว้แล้วโดย
การทำธุรกรรมที่มีอายุน้อยกว่าที่เป็นทีเอส (T ) <write_timestamp (x) ซึ่งหมายความว่าทรานส์แอ็กชัน T จะพยายามที่จะเขียนค่าล้าสมัยของรายการข้อมูล x T ทำธุรกรรม
ควรจะยกเลิกไปและเริ่มต้นใหม่โดยใช้เวลาต่อมา
(ค) มิฉะนั้นการเขียนสามารถดำเนินการต่อ เราตั้ง write_timestamp (x) = ทีเอส (T)
โครงการนี้เรียกว่าการสั่งซื้อเวลาขั้นพื้นฐานรับประกันว่าการทำธุรกรรมมีความขัดแย้ง
serializable และผลที่เทียบเท่ากับช่วงเวลาที่ต่อเนื่องในการที่ทำธุรกรรม
จะดำเนินการในลำดับของการบันทึกเวลา ในคำอื่น ๆ ผลจะ
เป็นถ้าทั้งหมดของการทำธุรกรรมที่ 1 ถูกประหารชีวิตแล้วทั้งหมดของการทำธุรกรรมที่ 2, และอื่น ๆ ที่ไม่มีระหว่างออกจาก แต่การสั่งซื้อเวลาขั้นพื้นฐานไม่ได้รับประกันตารางคืน
ก่อนที่เราจะแสดงให้เห็นว่ากฎระเบียบเหล่านี้สามารถใช้ในการสร้างตารางการใช้ timestamping,
ครั้งแรกที่เราตรวจสอบการเปลี่ยนแปลงเล็กน้อยในการโปรโตคอลนี้ที่ให้การทำงานพร้อมกันมากขึ้น

ผลลัพธ์ (ไทย) 3:

( 1 ) ธุรกรรม T ปัญหาอ่าน ( x )
( A ) รายการ T ขอให้อ่านรายการ ( x ) ที่ได้รับการปรับปรุงโดยน้อง
( ทีหลัง ) ธุรกรรมที่เป็นผู้หญิง ( T ) < write_timestamp ( X ) หมายความว่าธุรกรรมก่อนหน้านี้
พยายามจะอ่านค่าของสินค้าที่ได้รับการปรับปรุงโดยธุรกรรมในภายหลัง

รายการก่อนหน้านี้เป็นสายเกินไปที่จะอ่านค่า
เก่าก่อนหน้านี้และค่าอื่น ๆ มันได้รับมาอาจจะไม่สอดคล้องกับการปรับปรุง
ค่าของข้อมูลรายการ ในสถานการณ์นี้ ไม่ต้อง ยกเลิกรายการและเริ่มต้นใหม่กับใหม่
( หลังจากนั้น ) เวลา .
( B ) มิฉะนั้น TS ( T ) ≥ write_timestamp ( X ) และอ่านงานสามารถดำเนินการต่อ เราตั้ง read_timestamp
( X ) = max ( TS ( T ) , read_timestamp ( x ) ) .
( 2 ) ธุรกรรม T ปัญหาเขียน ( x )
( 1 ) ธุรกรรมทีขอเขียนรายการ ( X ) ที่มีค่าได้ถูกอ่านโดย
เด็กธุรกรรมที่เป็นผู้หญิง ( T ) < read_timestamp ( X ) นี้หมายความว่าการกระทำ trans ต่อมาได้ใช้ค่าปัจจุบันของรายการและมันจะผิดพลาด

update แล้ว ปัญหานี้เกิดขึ้นเมื่อรายการเป็นสายในมาเขียน และน้อง
ธุรกรรมได้อ่านค่าเก่า หรือเขียนใหม่ ในกรณีนี้ ,
ทางออกเดียวคือต้องย้อนกลับธุรกรรมและเริ่มต้นโดยใช้เวลาต่อมา .
( b ) ธุรกรรม T ขอให้เขียนรายการ ( X ) ที่มีค่าได้ถูกเขียนโดย
เด็กธุรกรรมที่เป็นผู้หญิง ( T ) < write_timestamp ( X ) นี้หมายความว่าการกระทำ trans t พยายามที่จะเขียนค่าล้าสมัยของรายการข้อมูล Xรายการ T
ควรรีดกลับไปเริ่มต้นใหม่โดยใช้เวลาต่อมา .
( C ) หรือ เขียนงานสามารถดำเนินการต่อ เราตั้ง write_timestamp ( ( X ) = ผู้หญิง ( T )
โครงการนี้เรียกว่าพื้นฐานเวลาการสั่งซื้อ รับประกันว่าธุรกรรมมีความขัดแย้ง
serializable และผลลัพธ์ที่ได้จะเท่ากับหมายเลขตารางที่ธุรกรรม
จะดำเนินการในลำดับของ timestamps .ในคำอื่น ๆผลจะเป็นถ้าทั้งหมดของธุรกรรม
1 ถูกประหารชีวิตแล้วทั้งหมด 2 รายการ , และดังนั้นบน กับ อินเตอร์ ไปแล้ว อย่างไรก็ตาม เบื้องต้นเวลาสั่งไม่ได้รับประกันตารางคืน .
ก่อนที่เราจะแสดงวิธีการกฎเหล่านี้สามารถใช้ในการสร้างตารางการใช้ timestamping
เราก่อน , ตรวจสอบการเปลี่ยนแปลงเล็กน้อยนี้โปรโตคอลที่ให้มากกว่าการเห็นพ้องด้วย