GarciaSagas
Paper
- long running tansactions are bad: they take up resources, cause deadlocks, and cause other transaction to wait or abort
- sagas are LLTs broken up into components. if one component fails, we can run a compensating one
- note that compensating actions could occur after another transaction has seen Ts changes
- syntax: begin-saga, begin-T, end-T, abort-T (doesn't abort saga), abort-saga, end-saga
- DB returns saga ID, passed on each T
- end-T must contain compensating T
- abort-T abort-saga not allowed in compensating T (how about DB aborted Ts?)
- save-point command: DB returns check point information that the app can start from in case of crash
- since application code is required for saga rollbacks, code needs to be backup/stored by DB
- sagas managed by saga execution component, Ts by TEC
- if there is an error in the C, you can either try and alternate C or manually fix the problem
- to implement this system on an existing DBMS, the SEC is seperate, but logs its information in the DB
- all of these commands (like end-transaction) need to happen *inside* the transactions
- saga deamon can scan running sagas, detect errors, run backward/forward routines
- concurrent running of Ts must notify SEC of forks and joins so it can figure out save-point dependencies and such
-
Lecture
- long running transaction and ACID mix poorly
- 2PC is unpopular across systems
- not all third party systems are transactional
- mixing short and long T result in:
- 2PL: deadlocks
- BTO: abortions, starvation
- MVTO: TODO: what? helps long reads, but writers suffer
- OPT: aborts
- usage cases for long running T:
- compute monthly X
- book a vacation: I want a bunch of stuff, but if I can't get everything, then fail
- add employee to system: phone, paychecks, office, etc
- sagas are just DB Ts
- each step is done in isolation
- all or nothing of Ts
- variations: backward and forward recovery
- compensations are application dependent
- user model:
- begin-saga -> saga-id
- abort-T (abort-saga)
- end-T (saga-end)
- compensation info includes:
- name
- entry point to compensation (java: class/package/method)
- parameters
- save points:
- tell the system: remember this point with some info (eg where I am in the app)
- can rollback to last save point using compensators, then roll forward
- what to do if compensation fails?
- retry, maybe with waits
- alternate compensators
- last resort: manual
- DBMSs use write ahead logging. rules:
- no change to public DB records until undo info is logged
- no commit of T until log info is forced
- also requires LSNs on pages so recovery can compare them against the log
- similarly, sagas:
- before T commits, log must reflect it
- make sure that during Ts, saga information is logged as well
- how to implement:
- shared log (assumes 1 system, exploits the fact that log is sequential on one box)
- SEC is able to pop things into the log
- need to augment log records with saga ID
- however, it turns out that:
- real problem being solved is business T processing problem
- multiple systems involved
- DBs don't support sagas (so build on top
- non-T steps are needed
- use a seperate "log" - implemented by a DB
- implemented by simply doing 2PC across 2 sites (the SEC and the other app)
-