Q.6)
1. Conflict Serializability (Takraav ko Handle Karna)
Basic Concept:
Jab bahut saare transactions ek sath chalte hain (concurrent schedule), toh humein yeh check karna hota hai ki kya unka final result waisa hi hoga jaise ki wo ek-ek karke (serial schedule) chale hote. Conflict serializability yahi check karne ka ek tarika hai.
Points ka Explanation:
- i) Swapping Non-conflicting Operations: Yeh kehta hai ki agar hum un operations (jaise Read/Write) ko aapas mein swap (upar-neeche) karein jo ek dusre se 'conflict' nahi karte, toh kya hum ek serial schedule bana sakte hain?
- Conflict kab hota hai? Jab 3 baatein sach hon: (1) Dono operations alag-alag transactions ke hon, (2) Dono same data par kaam kar rahe hon (jaise 'A' ki value badalna), aur (3) Unme se kam se kam ek operation 'Write' (kuch change karna) ho. (Jaise: Read-Write, Write-Read, ya Write-Write conflict).
- ii) Conflict Equivalence & Precedence Graph: Iska matlab hai ki agar do transactions ke beech conflict hai, toh unka jo order original schedule mein tha, wahi order final (serial) schedule mein bhi hona chahiye. Ise check karne ke liye hum ek Precedence Graph (Serialization Graph) banate hain. Is graph mein circles (nodes) transactions hote hain aur teer (arrows/edges) dikhate hain ki "Kaun kiske pehle aana chahiye".
- iii) Acyclic Graph (Bina chakkar wala graph): Ek schedule sirf tabhi conflict serializable hota hai jab uske graph mein koi 'cycle' (gol chakkar) na bane. Yeh ek aasan formula hai jisse computer jaldi calculate (polynomial-time) kar leta hai.
Yeh Kaam Kaise Karta Hai? (How it works)
- Sabse pehle transactions ke beech ke saare conflicting pairs (Read-Write, Write-Read, Write-Write) ko dhundho.
- Agar Transaction 1 (T1) ka operation pehle aaya aur Transaction 2 (T2) ka conflicting operation baad mein aaya, toh graph mein ek teer (arrow) banao: T1 → T2.
- Pura graph banne ke baad check karo ki kya koi cycle ban raha hai (jaise T1 → T2 aur wapas T2 → T1)? Agar cycle nahi hai, toh wo Conflict Serializable hai. Agar cycle ban gaya, toh wo nahi hai.
Example & Diagram (Conflict Serializability)
Schedule S: R1(X), W2(X), R3(X), W1(Y), W2(Y), R3(Y)
(Yahan 1, 2, 3 transaction numbers hain. R matlab Read, W matlab Write)
Conflicts dhundhte hain:
- R1(X) aur W2(X) → T1 pehle aaya, toh edge banegi: T1 → T2
- W1(Y) aur W2(Y) → T1 pehle aaya, toh edge banegi: T1 → T2
- W1(Y) aur R3(Y) → T1 pehle aaya, toh edge banegi: T1 → T3
[Precedence Graph Diagram]
[ T1 ]
/ \
/ \
v v
[ T2 ] -> [ T3 ]
Kyunki is graph mein teer ek hi disha mein ja rahe hain aur wapas ghum kar T1 par nahi aa rahe (koi cycle nahi hai), isliye yeh schedule Conflict Serializable hai. Iska serial order hoga: T1 pehle, fir T2, fir T3.
2. View Serializability (Result ko Dekhna)
Basic Concept:
Yeh conflict serializability se thoda advanced aur flexible (lenient) hai. Isme hum operations ko swap karne par dhyan nahi dete, balki yeh dekhte hain ki har transaction ko wahi data read/write karne ko mil raha hai ya nahi jo ek normal serial schedule mein milta.
Points ka Explanation:
- i) View Serializability ki 3 Shartein (Conditions):
- Initial Read: Jo transaction concurrent schedule mein sabse pehle data read kar raha tha, wahi serial schedule mein bhi sabse pehle read karna chahiye.
- Reads-from Relation (Update kisne kiya): Agar T2, T1 dwara update (write) ki hui value read kar raha hai, toh serial schedule mein bhi use wahi value milni chahiye.
- Final Write: Jo transaction sabse aakhiri (last) mein data write (save) kar raha tha, wahi serial schedule mein bhi aakhiri mein write karna chahiye.
- ii) View-Equivalent: Agar koi schedule kisi serial schedule ke sath yeh teeno shartein poori karta hai, toh use View Serializable kehte hain.
- iii) Weaker Criterion (Zada chhoot dena): Yeh conflict serializability se thoda flexible hai. Har Conflict Serializable schedule, View Serializable hota hi hai. Lekin kuch schedule jo Conflict Serializable nahi hote, wo bhi View Serializable ho sakte hain (khaas kar jab "Blind Write" ho).
Blind Write kya hai? Jab koi transaction kisi data ko bina pehle Read kiye direct Write (update) kar deta hai.
- iv) Harder to Decide: Ise check karna computer ke liye thoda mushkil aur lamba process hota hai kyunki isme har 'read' aur 'write' ka relation check karna padta hai.
Yeh Kaam Kaise Karta Hai? (How it works)
- Check karo ki sabse pehli value kisne read ki (Initial Read).
- Check karo ki kis transaction ne kiski likhi hui (written) value read ki hai. (Same relation serial mein hona chahiye).
- Check karo ki sabse last mein data ko kisne write kiya (Final Write).
- Iske basis par ek dependency graph banta hai. Agar blind write hai, toh cycle aane ke baad bhi kuch conditions mein use accept kar liya jata hai.
Example (Blind Write wala case)
Schedule S: R1(A), W2(A), R3(A), W3(A), W1(A)
Agar hum iska normal precedence graph banayenge toh isme cycle aa jayega. Isliye yeh Conflict Serializable NAHI hai.
Lekin agar hum isko closely dekhein:
- T1 sabse pehle Read kar raha hai.
- T2 uske baad bina read kiye Write kar raha hai (Blind Write).
Agar hum order thoda adjust karein, toh yeh shartein poori ho jati hain ki final data kisne likha aur kisne kiska data padha. Is wajah se, blind write ki wajah se conflict serializability fail ho jane ke baad bhi, yeh View Serializable ho sakta hai.
3. Summary (Types of Serializability ke 2 main types):
- Conflict Serializability: Yeh order aur takraav (conflict) par nirbhar karta hai. Ise check karna aasan hai. Precedence graph banate hain aur agar cycle nahi hai (acyclic), toh pass ho jata hai.
- View Serializability: Yeh actual padhe/likhe gaye data par nirbhar karta hai. Ise check karna mushkil hai. Yeh un schedules ko bhi pass kar deta hai jinme "Blind Writes" hote hain, jinhe Conflict Serializability fail (reject) kar deta hai.
Comments
Post a Comment