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)
  •