The birth of the open source enterprise stack
Posted Jul 5, 2006 19:48 UTC (Wed) by pimlott
In reply to: The birth of the open source enterprise stack
Parent article: The birth of the open source enterprise stack
it's amazing how often huge systems can get away without using transactions
It is amazing, but it doesn't make it right! When something finally does go wrong, it's extremely hard to debug and fix. Yes, I know, sometimes the cost of cleaning up the occasional mess is lower than the cost of doing it right. But given the ubiquity of DBMSs with transactions, it's hard to see why you'd risk it.
The PostgreSQL manual makes the point that perfect isolation isn't possible without giving the database what amounts to a theorem prover *and* complete knowledge of your app's control flow
I'm curious what you're talking about, because I can't find anything like that in the PostgreSQL manual. I think perfect isolation is straightforward using read and write logs, and that PostgreSQL does exactly that. What am I missing?
that perfect isolation isn't possible without giving the database what amounts to a theorem prover *and* complete knowledge of your app's control flow: but most databases, including major expensive ones with clowns with E in their surnames as CEOs of their controlling company, don't even try: you have to *ask* for half-decent isolation, and when you do your transaction goes read-only!
I agree that they don't even try. It's a travesty that the isolation level required for reliability in most applications--that the SQL standard says must be the default--is not the default in any DBMS I know. And when you do turn it on, many systems perform badly; PostgreSQL, with multi-version concurrency control, does quite well. But what do you mean about transactions going read-only?
to post comments)