Your SlideShare is downloading. ×
Dennis van der Stelt
What you probably
didn’t know about them
Dennis van der Stelt
Software Architect
http://bloggingabout...
Dennis van der Stelt
AGENDA
Dennis van der Stelt
“You know nothing, Jon Snow”
Dennis van der Stelt
WHAT IS A TRANSACTION?
Dennis van der Stelt
Everything is a transaction
ACID PROPERTIES
Dennis van der Stelt
prevent logfile from
growing unexpectedly?
Dennis van der Stelt
DIFFERENT TYPE TRANSACTIONS
Auto commit
transactions
Explicit
transactions
Implicit
transactions
Batc...
Dennis van der Stelt
TRANSACTION & CONCURRENCY EFFECTS
All transactions occurin isolation.Yeah, right!
Two transactions
up...
Dennis van der Stelt
TRANSACTION ISOLATION LEVELS
read uncommitted
read committed (default)
repeatable read
serializable02...
Dennis van der Stelt
transactions & performance
Dennis van der Stelt
SCALING OUT
Horizontally add more servers
easily scale out webservers
how about that database?
Dennis van der Stelt
SCALING OUT
Horizontally add more servers
can we scale out our rdbms?
Dennis van der Stelt
CAP Theorem
Eric Brewer, PODC Conference 2000
Dennis van der Stelt
CAP THEOREM
You can only pick 2
Dennis van der Stelt
CAP THEOREM
You can only pick 2
centralized
system
partition tolerantconsistencyavailability
Dennis van der Stelt
CAP THEOREM
You can only pick 2
centralized
system
partition tolerantconsistencyavailability
Dennis van der Stelt
CAP THEOREM
You can only pick 2
centralized
system
partition tolerantconsistencyavailability
distribu...
Dennis van der Stelt
CAP THEOREM
You can only pick 2
centralized
system
partition tolerantconsistencyavailability
distribu...
Dennis van der Stelt
Match the business perspective
Dennis van der Stelt
Dennis van der Stelt
Dennis van der Stelt
Dennis van der Stelt
But I can’t drop consistency!
Dennis van der Stelt
Basically Available
BASE
What is BASE?
Soft state
Eventually consistent
Dennis van der Stelt
NEIGHBOR’S WIFE
EVENTUAL CONSISTENCY
NEIGHBOR
YOU
DENNIS
?
time
Dennis van der Stelt
Eventual Consistency
Dennis van der Stelt
Eventual Consistency
Dennis van der Stelt
Eventual Consistency
your “enterprise” is already eventual consistent with reality
Dennis van der Stelt
Eventual Consistency
your “enterprise” is already eventual consistent with reality
Dennis van der Stelt
CAP THEOREM
Patterns for success
Asynchronous Messaging NoSQL
Eventual consistency Event Driven Archi...
Dennis van der Stelt
NOSQL
Dennis van der Stelt
ASYNCHRONOUS MESSAGING
Solves temporal & spatial coupling
readonly read/write
Dennis van der Stelt
EVENT DRIVEN ARCHITECTURE
i’ll answer your question before you know you have one
but not today, becau...
Dennis van der Stelt
Distributed Transactions
Dennis van der Stelt
no two phase commit at starbucks
Dennis van der Stelt
DISTRIBUTED TRANSACTIONS
“eBay doesn’t do transactions … because of
availability concerns”
Dan Pritch...
Dennis van der Stelt
DISTRIBUTED TRANSACTIONS
“There’s data we’re willing to lose … doesn’t
mean we don’t care about your ...
Dennis van der Stelt
DISTRIBUTED TRANSACTIONS
“we want the database to be an
essentially reliable data store and keep
as m...
Dennis van der Stelt
IDEM POTENCY
Solving the distributed transactionissues
Sender
Dennis van der Stelt
IDEM POTENCY
Solving the distributed transactionissues
Sender
{0C836F44-6587-416E-B97A-5615615600D5}
Dennis van der Stelt
IDEM POTENCY
Solving the distributed transactionissues
Sender
Event
Subscriber
{0C836F44-6587-416E-B9...
Dennis van der Stelt
IDEM POTENCY
Solving the distributed transactionissues
Sender
Event
Subscriber
{5EDC4993-AB01-4F17-A2...
Dennis van der Stelt
AGENDA
Dennis van der Stelt
Thank you
questions?
Dennis van der Stelt
Software Architect
http://dennis.bloggingabout.net/
@dvdste...
Upcoming SlideShare
Loading in...5
×

Transactions

676

Published on

Why are transactions the bottleneck of so many applications? Why isn't the database always consistent, even though we use transactions? This session explains why everything in a database is a transaction and how a developer should deal with them. Why your software complains that MSDTC isn't running and how the CAP Theorem can help. After this session you'll be able to explain to your DBA why he doesn't understand transactions.

Published in: Technology
1 Comment
1 Like
Statistics
Notes
  • Thanks for your good presentation!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
676
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide
  • Disclaimer : Jon Snow doesn’t know everything, me neither! ;-)Ikwillatenzienwattransactiesbetekenen en waterfoutkangaan.Ikwilooklatenzien hoe je anders met transactiesomkuntgaan.
  • Is een “select” statement een transaction?Wiedenktdit? Wiedenkt van niet?Een database modificatie in iedergevalCreate database is niettransactioneel
  • Isolation means that one transaction cannot read data from another transaction that is not yet completed.Durability: SQL Server doetnietaan software & hardware cacheomzekertezijndat het op disk staat.
  • KB 317375KB article iszelfdeals “Hoe tevoorkomendat je auto constant onverwachtzonderbenzine zit”Logfile is even more important than datafile!Disk performance crucial (sequential writes)Backup frequently!Full = allesloggenBulk-logged = index wél, data nietelke row, enkel pagesSimple = geen rows, geen index, welalleacties
  • Auto commit = Every statement auto commits. You don’t know you’re using itExplicit = You explicitly start and commit your transactions (BEGIN TRAN)Implicit = Setting in SQL, you only have to commit. SQL starts it for you. Not popularMARS = Multiple Active Result Sets, execute multiple queries on single connection. Pretty exotic.
  • Repeatable read : Shared lock, you can read, but not updateSnapshot : Try to update something that was updated by someone else, you’ll get error message
  • Commit requires synchronous disk writeTransaction log I/O throughput is important!Higher isolation = more locking = less concurrencyNeed to find balanceControl size of transacitons
  • This says : “Sorry, we can’t take your money right now!”
  • This says : “Sorry, we can’t take your money right now!”
  • This says : “Sorry, we can’t take your money right now!”
  • Basically available indicates that the system does guarantee availability, in terms of the CAP theorem.Soft state indicates that the state of the system may change over time, even without input. This is because of the eventual consistency model.Eventual consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time.
  • Dennis tells you that it's going to rain tomorrow.Your neighbor tells his wife that it's going to be sunny tomorrow.You tell your neighbor that it is going to rain tomorrow.At some point, the wife will know… Eventually!Eventual => Not consistent at 1 point in time, but eventually it will!
  • The trucks are delivering the beer, your system is starting to bill the customer
  • But unfortunately, something bad happens along the way
  • The system is billing, but the beer is never delivered to the customer
  • In the end it’ll be alright, because we do not want to disappoint these fine ladies, would we?! 
  • NoSQL = Not Only SQLNoSQL = Read optimization vs Write optimization (SQL)NoSQL = build to scaleNoSQL = weaker consistency models, but greater performanceNoSQL = DocumentDb, and documents are objects. No more mapping!NoSQL = Because of distributed nature, they are always on! No downtime, even when changing hardware!NoSQL = Not for every case
  • Normal distributed transactionMessages is processed transactionallyPulled from queueChange business dataTransaction completes
  • What do you like more?Changing other people’s code?Or writing new code?
  • What do you like more?Changing other people’s code?Or writing new code?
  • What do you like more?Changing other people’s code?Or writing new code?
  • Normal distributed transactionMessages is processed transactionallyPulled from queueChange business dataTransaction completes
  • Without distributed transactionsNeed to verify is message has already been processedProvide MessageIdChange business dataWrite MessageId into databaseDatabase transaction completesWhen message arrives again, we check stored idsWhen crash occurs, everything’s fine. Right?WRONG
  • What if we send out a message?What if we crash after publish, but before data was committed? No event!Or vice versa? Double events, but different message ids!
  • Need to ‘record’ all sends and publishesStore these in additional databaseSend them after all handlers are doneBut…What if we’ve send out 3 out of 6 events and we crash?When service starts, we need to retry sending msgsOther side needs to be idempotent as well!!!Never said it was easy! 
  • Transcript of "Transactions"

    1. 1. Dennis van der Stelt What you probably didn’t know about them Dennis van der Stelt Software Architect http://bloggingabout.net/blogs/dennis/ @dvdstelt dvdstelt@gmail.com TRANSACTIONS
    2. 2. Dennis van der Stelt AGENDA
    3. 3. Dennis van der Stelt “You know nothing, Jon Snow”
    4. 4. Dennis van der Stelt WHAT IS A TRANSACTION?
    5. 5. Dennis van der Stelt Everything is a transaction
    6. 6. ACID PROPERTIES
    7. 7. Dennis van der Stelt prevent logfile from growing unexpectedly?
    8. 8. Dennis van der Stelt DIFFERENT TYPE TRANSACTIONS Auto commit transactions Explicit transactions Implicit transactions Batch scoped transactions (MARS) Distributed transactions
    9. 9. Dennis van der Stelt TRANSACTION & CONCURRENCY EFFECTS All transactions occurin isolation.Yeah, right! Two transactions updating same row based on original value Fixed by read lock … or a retry ;-) Two transactions on the same data where one reads data not yet committed Fixed by read committed isolation Two transactions where one reads different values every single time Fixed by repeatable read isolation Reading different values within single transaction Needs index for range locks Fixed by serializable isolation SQL Server only! Index/scan issue Rows are moved during table scan Fixed by read committed isolation
    10. 10. Dennis van der Stelt TRANSACTION ISOLATION LEVELS read uncommitted read committed (default) repeatable read serializable02 03 04 01 Version based, optimistic concurrency control - SQL Server 2005+ read committed snapshot05 snapshot06 Lock based, pessimistic concurrency control
    11. 11. Dennis van der Stelt transactions & performance
    12. 12. Dennis van der Stelt SCALING OUT Horizontally add more servers easily scale out webservers how about that database?
    13. 13. Dennis van der Stelt SCALING OUT Horizontally add more servers can we scale out our rdbms?
    14. 14. Dennis van der Stelt CAP Theorem Eric Brewer, PODC Conference 2000
    15. 15. Dennis van der Stelt CAP THEOREM You can only pick 2
    16. 16. Dennis van der Stelt CAP THEOREM You can only pick 2 centralized system partition tolerantconsistencyavailability
    17. 17. Dennis van der Stelt CAP THEOREM You can only pick 2 centralized system partition tolerantconsistencyavailability
    18. 18. Dennis van der Stelt CAP THEOREM You can only pick 2 centralized system partition tolerantconsistencyavailability distributed system partition tolerantconsistencyavailability
    19. 19. Dennis van der Stelt CAP THEOREM You can only pick 2 centralized system partition tolerantconsistencyavailability distributed system partition tolerantconsistencyavailability when there’s network partition, which do you sacrifice?
    20. 20. Dennis van der Stelt Match the business perspective
    21. 21. Dennis van der Stelt
    22. 22. Dennis van der Stelt
    23. 23. Dennis van der Stelt
    24. 24. Dennis van der Stelt But I can’t drop consistency!
    25. 25. Dennis van der Stelt Basically Available BASE What is BASE? Soft state Eventually consistent
    26. 26. Dennis van der Stelt NEIGHBOR’S WIFE EVENTUAL CONSISTENCY NEIGHBOR YOU DENNIS ? time
    27. 27. Dennis van der Stelt Eventual Consistency
    28. 28. Dennis van der Stelt Eventual Consistency
    29. 29. Dennis van der Stelt Eventual Consistency your “enterprise” is already eventual consistent with reality
    30. 30. Dennis van der Stelt Eventual Consistency your “enterprise” is already eventual consistent with reality
    31. 31. Dennis van der Stelt CAP THEOREM Patterns for success Asynchronous Messaging NoSQL Eventual consistency Event Driven Architecture Read up on these topics! No distributed transactions
    32. 32. Dennis van der Stelt NOSQL
    33. 33. Dennis van der Stelt ASYNCHRONOUS MESSAGING Solves temporal & spatial coupling readonly read/write
    34. 34. Dennis van der Stelt EVENT DRIVEN ARCHITECTURE i’ll answer your question before you know you have one but not today, because you have no idea how many you have
    35. 35. Dennis van der Stelt Distributed Transactions
    36. 36. Dennis van der Stelt no two phase commit at starbucks
    37. 37. Dennis van der Stelt DISTRIBUTED TRANSACTIONS “eBay doesn’t do transactions … because of availability concerns” Dan Pritchett on architecture at eBay
    38. 38. Dennis van der Stelt DISTRIBUTED TRANSACTIONS “There’s data we’re willing to lose … doesn’t mean we don’t care about your data, it just means we care about different types of your data in different ways.” Dan Pritchett on architecture at eBay
    39. 39. Dennis van der Stelt DISTRIBUTED TRANSACTIONS “we want the database to be an essentially reliable data store and keep as much stuff as possible in logic so that we have more control over it. The same reason why we don't use stored procedures: anything that happens in the database is invisible to developers” Dan Pritchett on architecture at eBay
    40. 40. Dennis van der Stelt IDEM POTENCY Solving the distributed transactionissues Sender
    41. 41. Dennis van der Stelt IDEM POTENCY Solving the distributed transactionissues Sender {0C836F44-6587-416E-B97A-5615615600D5}
    42. 42. Dennis van der Stelt IDEM POTENCY Solving the distributed transactionissues Sender Event Subscriber {0C836F44-6587-416E-B97A-5615615600D5} {5EDC4993-AB01-4F17-A238-71C4521F750F}
    43. 43. Dennis van der Stelt IDEM POTENCY Solving the distributed transactionissues Sender Event Subscriber {5EDC4993-AB01-4F17-A238-71C4521F750F} {0C836F44-6587-416E-B97A-5615615600D5}
    44. 44. Dennis van der Stelt AGENDA
    45. 45. Dennis van der Stelt Thank you questions? Dennis van der Stelt Software Architect http://dennis.bloggingabout.net/ @dvdstelt dvdstelt@bloggingabout.net

    ×