3 ms·
While transactions are generally important for, well, monetary transactions, they're not necessary in your example. You could just: Update Balances Cal
by reissbaker 13y ago
While transactions are generally important for, well, monetary transactions, they're not necessary in your example. You could just:
Update Balances
Call CC Processor
And if updating balances threw an exception, you'd never reach the Call CC Processor statement. In fact, putting it inside of a transaction is more dangerous than not as the following example demonstrates:
Start Transaction
Update Balances
Call CC Processor
OH SHIT APPLICATION PROCESS DIES (or network partition, etc etc)
DB connection is terminated
Updated balances roll back
But you still charged your customers' cards
And destroyed your primary record of it
Hope you didn't have any other work planned this week
And unfortunately the above tends to happen more often than you'd expect.
- MichaelGG 13y agoHence, I mentioned if you're worried about commits failing (not a major recurring issue that I've seen but possible), the n you do two separate transactions.
- reissbaker 13y agoNope. You'd do at most one transaction, around the transactional part. You wouldn't wrap an external call in a transaction: if it's not transactional, you're literally doing nothing but adding load to your database. If your DB doesn't have access to the data, the transaction is meaningless: your database can't roll back the state. And if the Update Balances call is a single SQL statement, you actually wouldn't use any transactions at all. You'd just issue the write and have it be written. No point adding the overhead of a transaction if it isn't doing anything.