X'inhuma l-livelli ta' isolation tat-transakzjonijiet?

Question

Accepted Answer

**Livelli ta' isolation** jikkontrolla kemm jistgħu jraw it-transakzjonijiet konkorrenti l-bidliet uncommitted (jew in-progress) ta' xulxin — jiskambljaw **konsistenza** kontra **prestazzjoni/concurrency**. Livelli ta' isolation ogħla jipprevjenu aktar anomaliji imma jżidu l-locking/contention. ## L-anomaliji ta' concurrency (dak li l-isolation jipprevjeni) ```text DIRTY READ → reading another transaction's UNCOMMITTED changes (which may roll back) NON-REPEATABLE READ → re-reading a row gives different values (another txn UPDATED it) PHANTOM READ → re-running a query returns different ROWS (another txn INSERTED/DELETED) ``` Ħadd dawn il-problemi li jistgħu jseħħu meta t-transakzjonijiet jużu concurrent — livelli ta' isolation jikkontrolla liema minnhom jipprevnjew. ## Il-erba' livelli standard ta' isolation ```text Level | Dirty Read | Non-repeatable | Phantom | Concurrency ────────────────────────────────────────────────────────────────────── READ UNCOMMITTED | possible | possible | possible| highest (least safe) READ COMMITTED | prevented | possible | possible| (common default) REPEATABLE READ | prevented | prevented | possible| SERIALIZABLE | prevented | prevented | prevented| lowest (most safe) ``` Kull livell ogħla jipprevjenu aktar anomaliji. **Read Committed** huwa default komuni (jipprevjeni dirty reads); **Serializable** huwa l-iktar strikt (it-transakzjonijiet iżommu bħallikieku jużu wieħed wara l-ieħor) imma l-iktar restrittiv għal concurrency. ## Issettjar il-livell ta' isolation ```sql SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN; -- ... operations run at the chosen isolation ... COMMIT; ``` ## L-iskamb fundamentali ```text Higher isolation → MORE correctness (fewer anomalies), but MORE locking/contention → lower concurrency, potential slowdowns, more deadlocks Lower isolation → MORE concurrency/performance, but risk of anomalies → Choose based on the data's needs: financial/critical data may need Serializable; most apps use Read Committed (the default) as a balance. → Note: implementations vary (MVCC vs locking); the SQL standard defines the levels but databases differ in details (Postgres, MySQL/InnoDB, etc.). ``` ## Għaliex importa Livelli ta' isolation tat-transakzjonijiet huma għarfien avanżat importanti biex tifhem **concurrency fil-databases** — meta transakzjonijiet multipli jużu simultanjament (kif jiġri f'kwalunkwe applikazzjoni reali multi-user), livelli ta' isolation jiddeterminaw l-iskamb bejn konsistenza tad-data u prestazzjoni, għalhekk tifhimu huwa valuwuż għad-disinn ta' applikazzjonijiet concurrent korretti u performanti. Il-kunċetti essenzjali huma l-**anomaliji ta' concurrency** (dirty reads, non-repeatable reads, phantom reads — il-problemi li jinqalgħu meta transakzjonijiet jifhmew il-bidliet in-progress ta' xulxin) u kif il-**erba' livelli ta' isolation** (Read Uncommitted, Read Committed, Repeatable Read, Serializable) jipprevjenu progressivament aktar minnhom. Tifhim dan huwa importanti għal-korrettezza: jekk tagħżel livell ta' isolation baxx wisq, jista' jippermetti anomaliji li jikkorupaw id-data jew jipproduċu riżultati ħażin (eż. qari tad-data uncommitted li aktar tard jirragel lura, jew qari inkonsistenti), filwaqt li tagħżel wisq għoli jnaqqas il-concurrency u l-prestazzjoni. L-**iskamb fundamentali** — isolation ogħla jiġifieri aktar korrettezza imma aktar locking/contention (concurrency iktar baxxa, ralentament potenzjali u deadlocks), isolation baxxa jiġifieri aktar prestazzjoni imma riskju ta' anomaliji — huwa l-insight ewlieni: tgħażel il-livell ibbażat fuq ir-rekwiżiti ta' konsistenza tad-data (data kritika/finanzjarja jista' jkollu bżonn Serializable; ħafna applikazzjonijiet jużaw Read Committed bħala bilanċ). "}}