On 3/25/2011 2:48 PM, m.roth at 5-cent.us wrote: > >>> Well... except that in this context, it's not only database >>> transactions: it's any granular interaction between client and server. >>> You don't, for example, want part of a form you've just clicked<submit> >>> on to only partly get there, if there's a network blip or whatever. >> >> If 'get there' is defined as all redundant copies being in a consistent >> state, then you'll fail at this point in transactional mode in the >> fairly likely event that you have a network blip between the db master >> and slave(s) or one of them is down. For a lot of things it would be > <snip> > Les, ignore d/b. Think of you submitting, from your browser, a request for > something, and the transaction is incomplete, and it gets to the server, > and instead of getting what it was allowed to, it gets something below > that level, that it's *not* allowed to get, and you really *don't* want > accesible, but it can do it as apache.... > > Or something as trivial as requesting something, and your email address is > truncated. That doesn't really relate to distributed vs. non-distributed or transactional vs non-transactional. That's just application level stuff. > BEA doesn't make Big Bucks for Tuxedo, for example, only for d/b > transactions. I thought it was about making multiple separate things that might have their own transactional concepts have an upper level transaction that either fails or completes consistently. That is, it favors the C (consistency) in CAP over availability. The cloud DB's tend to favor availability even when consistency can't be guaranteed temporarily, or they give the client the opportunity to control the consistency level it wants for any operation (i.e. wait for n number of writes to be completed, read n copies with their clock vector, etc.). -- Les Mikesell lesmikesell at gmail.com