And in case you think there's a general solution to that problem, there isn't: https://en.wikipedia.org/wiki/CAP_theorem Still, it's funny how banking seems to be the canonical example for why we need transactions given that most banking transactions are inconsistent ( http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on... ).
Consistency is Consistently Undervalued
11–20 of 131 posts
Re: Consistency is Consistently Undervalued
#12Re: Consistency is Consistently Undervalued
#13But consider this: You are using mysql, you make a transaction with say deposit and withdraw. What happens on the mysql machine if you pull the plug exactly when mysql has done the deposit but not the withdraw? The ONLY difference between SQL transactions and NoSQL microservice transactions is the time between the parts of a transaction. Personally I use a JSON file with state to execute my NoSQL microservice transac…
There are no "parts of a transaction" because a transaction is definitionally atomic.
Transactional file modification is a fairly tricky problem, and I'd be surprised if you'd actually implemented a safe system in that manner. What's certain though is that spinning up MySQL or Postgres and using it to store simple records is essentially a zero-cost setup task - so I doubt it's ever going to "hog all your time and resources".
Re: Consistency is Consistently Undervalued
#14Re: Consistency is Consistently Undervalued
#15In these environments you atomically create objects in your application's "local" storage and have a reconciliation loop for creating objects in other services or deleting these orphan "local" objects.
Re: Consistency is Consistently Undervalued
#16I've stopped using bank transfers as an example for Acid transactions, and instead talk about social features:
- if I change a privacy setting in Facebook or remove access to a user, these changes should be atomic and durable
- transactions offer a good semantic of which to make these changes. They can be staged in queries, but nothing is successful until after a commit.
- without transactions durability is hard to offer. You would essentially need to make each query flush to disk, rather tha each transaction. Much more expensive.
Re: Consistency is Consistently Undervalued
#17I think it's a bad example because this should not be the way to develop in this kind (microservices) of systems. In these environments you atomically create objects in your application's "local" storage and have a reconciliation loop for creating objects in other services or deleting these orphan "local" objects.
Re: Consistency is Consistently Undervalued
#18Why isn't the OP using Event Sourcing "commands" for the "Bank Accounts" example?
Re: Consistency is Consistently Undervalued
#19Re: Consistency is Consistently Undervalued
#20Why isn't the OP using Event Sourcing "commands" for the "Bank Accounts" example?
Edit: I wasn't familiar with the terminology, but it sounds like what I have written about here: http://kevinmahoney.co.uk/articles/immutable-data/