On 3/25/2011 2:11 PM, m.roth at 5-cent.us wrote: > >>> Not everything deals in transactions, though. The recently popular >>> distributed database versions that scale up are more about doing >>> something reasonable in scenarios where you can't guarantee a >>> transaction state (where 'reasonable' is defined by the application). >>> > 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 better to keep running with timestamp or clock vectors on the data that will be used to track the multiple versions you'll have as the system reconverges. I'd expect Amazon's shopping cart to work that way, although they might do something more transactional when finalizing a purchase. -- Les Mikesell lesmikesell at gmail.com