[crntaylor]

In case it's not clear to you, there are two reasons that you are getting downvoted: 1. snark, and 2. you are committing the logical fallacy of affirming the consequent. [0]

In particular, dijit asserted that "Not ACID => Not secure" (which is debatable, but that doesn't matter here) from which you can also validly deduce the contrapositive "Secure => ACID". However, you then (sarcastically) asserted that dijit is saying "ACID => Secure", whereas in fact he said nothing like that.

[0] http://en.wikipedia.org/wiki/Affirming_the_consequent

[hack3r_n3ws]

I don't think you understand what is being discussed. ACID compliance has nothing to do with "security". It's a matter of transactional guarantees. MongoDB offers none because it is not ACID compliant. That means that transactions can silently fail, partially commit, execute out of order, etc. This is an EXTREMELY serious and complicated issue. And I would not do any banking, trading, etc on a non-compliant database.

[crntaylor]

If it helps, you can replace "Secure" with "X" where X is any adjective, and my argument will still work.

[snupples]

Now you're just arguing semantics

[pessimizer]

Security in the integrity of your data, rather than security from an invader. Also Non-ACID => Non-"Michael Jackson," therefore ACID => "Michael Jackson" is just as wrong, so you're comment isn't really relevant.

[btown]

You're taking a very restricted definition of "security." I'd say that if my data has a high chance of being corrupted, it's insecure, whether or not there's a malicious party involved or not. For that matter, if there's a possibility of data corruption when there's lots of concurrency, then it's worse than a malicious party, because it's almost guaranteed to bite you when you need to scale quickly, whereas a hacker might not target you right away.