Monty Taylor wrote:
Jim Starkey wrote:
Jeremy Zawodny wrote:
On 10/14/08, *Ask Bjørn Hansen* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Oct 13, 2008, at 10:55, Jim Starkey wrote:
You are right if you think about transaction context. The
thing is most web shops, almost all, run in autocommit
mode. This is the 80% case (if not more). Of course when
you run within the context of a transaction you have an
issue, I mentioned that in my original email, but the
majority case does not do this. They fire off seven
queries, get the results, and then build a page.
Gosh, Brian, that's a pretty good argument for an aggregating
interface. Of course then they would have a single
transaction and the results would even be consistent.
I think that's missing the point a little pushing the
transactions. :-) Not using transacions isn't just being lazy; in
many applications most queries can be done safely without
transactions. Spending any CPU cycles on them would just be wasted.
Not to mention disk I/O.
Yup, where getting the right answer doesn't matter, non-transactional
engines are the way to go. The historically oriented might point out
that databases were invented to give consistent answers in a volatile
environment, but that was on a parallel universe somewhere.
This isn't about transactional vs. non-transactional or even about
getting the wrong answer. For most of these shops, the transactional
ability is useful for some of the queries - usually a very small number
of them. It's the transaction isolation that's useless for a large
number of the queries. (Or, to be clear, keeping the same transactional
context for the purposes for isolation - I'm sure that no one wants the
underlying data to change out from under a single query)
So if one query gets one set of data (say, the address for "The Ivy" on
that page Ask sent) and another query gets something else (say, the list
of accepted payment methods) ... if someone in an admin interface
changed the list of payment methods after the address query was run but
before the payment methods query - NO ONE cares. Keeping context is
honestly retarded.
The funny thing is that some of the stuff built for the purposes of
transactions (MVCC etc) are actually quite useful for these folks. (One
of the main reasons no one really uses MyISAM any more) Just not all of it.
Yes, that's why I invented MVCC -- to make transactions easier to use
than not and making sure that writers don't block readers.
Serializability is an academic concept of little use for the real word.
But ACID is fundamental. Have two related updates be atomic is critical
to everyone. So is seeing a consistent view of the database. And not
seeing records that are subsequently backed out has a certain charm, also.
But the real question isn't about transactional or non-transactional,
but whether the infrastructure is designed to encourage, discourage, or
actively penalize transactions. For example, if you require a client to
use a number of parallel independent connections to get performance,
you've made an architectural commitment that makes consistent
transactions either impossible or at an unacceptable cost.
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
