• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,362
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
47
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • LLT - Long lived transactions - Hector Garcia-Molina 87 Top level is a business transaction Does not comply to ACID Requires compensating actionsSecond level is acid compliantAnalyze the business to find the boundaries Add messages -> in order to make each step as short as possible + forward movement only
  • Developers tends to do the same mistakes today
  • Top level is a business transaction Does not comply to ACID Requires compensating actionsSecond level is acid compliantAnalyze the business to find the boundaries Add messages -> in order to make each step as short as possible + forward movement only
  • One way messaging only to keep transaction as short as possible More scalable and robust http://www.udidahan.com/2008/06/23/sagas-solve-stupid-transaction-timeouts/ Can execute “steps” in parallelSaga instances are not run in parallelUse locks in DB to ensure that
  • Not a hard rule Sagas are useful for other non DDD related things
  • Sagas operate within a BC Can react to events from other BC’s
  • Saga message handlers have state

Transcript

  • 1. What’s this “Saga” thing that everyone is talking about?
    • @andreasohlund
    • http://andreasohlund.net
  • 2. What is a long running process?
    • “A long running process is a process whose execution lifetime exceeds the time to process a single external event or message”
    • - Udi Dahan
  • 3. Long running process Step Step Step Step Step Start End Start
  • 4. The problem
    • Holding locks for the duration of a long running transaction are more likely
      • To be deadlocked
      • To experience infrastructure failures
  • 5. Two levels of transactions
    • First level is a business transaction
      • Does not comply to ACID
      • Requires compensating actions
    • Second level is acid compliant
      • Analyze the business to find the boundaries
  • 6. Long Lived Transactions Step Step Step Step Step Start End Business Transaction ACID ACID ACID ACID ACID
  • 7. The anatomy of a step Step Get current state Store
  • 8. Sagas vs Aggregate roots Saga AR Event Command Event Command
  • 9. Sagas and bounded contexts Saga AR Bounded context Event Command External Event
  • 10. The birth of a saga Bus DB Store state Saga message Saga instance Create Dispatch Send Saga Persister Save
  • 11. Existing sagas Bus Message Dispatch Send Save DB Load/Store Saga Persister Get Saga instance State
  • 12. State
    • Remember what steps have been executed
    • Gets persisted between each step
    • Temporary storage of data
    • Serialize access to the same saga instance
      • Unique index
      • Locking
  • 13. Time
    • Long running transactions
    • Time is a business requirement
    • Needs to be durable and managed externally
  • 14. Sagas help throughput
    • Can execute “steps” in parallel
    • Saga instances are not run in parallel
      • Use locks in DB to ensure that
  • 15. Versioning
    • Long running == high probability that new versions must be compatible with older state
      • Either patch DB
      • or write back compat code
  • 16. How do sagas wake up?
    • Messages need to contain id:s for correlation
      • Non technical
  • 17. What happens when they are dead?
    • The big void
      • state is no longer relevant
    • But their children lives to tell the story
      • Other entities gets updated to reflect the outcome of a saga
    • todo: image black hole/gravestone
  • 18. Shit happens
    • Compensating actions
      • You decide
    • Retry of individual messages
    • Strive for forward recovery only