Jim,

> Dalton, that is so much nonsense. NuoDB is an existence proof that your
> assertion is false.
>
> There are lots of ways to make distributed transactions ACID without
> queries being run "atomically upon multiple systems." I demonstrated
> one, but stopped looking after that. The inquisitive mind may want to
> keep looking.
>
> Every time some says something like "The only way to ..." innovation is
> trampled. If I had believed that "the only way to implement consistent
> transactions is two phase locking" MVCC, Interbase, and Firebird
> wouldn't exist.
>
> Programmers have learned count "zero, one, two, infinity". There is
> never only one way to do something. There are the ways you know and the
> ways you haven't thought of. If you stop looking, you'll never find them.
>
> There are many people who believe that all of the good ideas have been
> discovered. They're wrong.

Hope you don't mind two questions on NuoDB:

* Is NuoDB fully solving the CAP theorem for distributed environments?
Or e.g. is it eventually consistent when reading data?

* How does the asynchronous replication approach (if I got that right?)
in NuoDB with the nature of synchronous JDBC calls, e.g. executeUpdate
blocks until it's finished etc.



Thanks,
Thomas

> On 1/22/13 9:35 AM, Dalton Calford wrote:
>>
>>
>>
>> *The only way to become fully ACID compliant is to house multiple
>> servers,**
>> **in multiple nocs, with queries being run atomically upon multiple
>> systems**
>> **in parallel so that if one system fails while processing work, the**
>> **secondary system can respond as it has already been doing the same
>> work as**
>> **the primary. * The clients and tiers need to be able to determine if the
>> answer they are getting is authoritative or non-authoritative. They need
>> to be able to deal with multiple responses to the same query and all work
>> is queue'd locally in case the entire local work process needs to be
>> re-applied (either immediately or delayed due to network latency/drops).
>>
>> It is a very complex subject that involves the design of the pop, the
>> power
>> for the pop, the full system redundancy for each cluster, with full drive
>> redundancy in the sans, with the client software and middle tier software
>> designed to handle a complete system failure and switch-over to a totally
>> different pop in a different city/province/country if needed.
>>
>> Ram drives work, but I normally use them for the temp drive. The
>> benefits of ram drives depend upon the version of firebird, the version of
>> the OS and the hardware parameters.
>>
>> If firebird is proposing going down that route, they would need to
>> implement some new structures in Firebird, mirroring some of the elements
>> that oracle and other database platforms have created.
>>
>> On 22 January 2013 08:51, Roman Simakov roman.simakov@...
>> <mailto:roman.simakov%40red-soft.biz>> wrote:
>>
>>> **
>>>
>>>
>>> 2013/1/22 Sergey Mereutsa serj@... <mailto:serj%40dqteam.com>>:
>>>
>>>> Hello Alex,
>>>>
>>>> and without shadow ACID rule has effect too - RAM-drive is the same
>>> block device as usual HDD - until power is not lost :)
>>>
>>> In this case you have ACI but have no D.
>>>
>>>
>>>
>>