• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

GarciaSagas

Page history last edited by PBworks 16 years, 11 months ago

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

Comments (0)

You don't have permission to comment on this page.