On 3/25/2011 2:48 PM, m.roth@xxxxxxxxx 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
