Talk:ACID

message: ACID is IMHO a property of transactions in general, not necessarily in the context of DBMS.
This should at least be mentioned.  —Preceding unsigned comment added by 193.135.254.161 (talk) 09:19, 14 January 2010 (UTC)
thread_title: DBMS Only?

message: I propose that the ACID article, being a disambiguation page, should mention both acid as in acidic chemicals, and also maybe mention that it is a nickname of LSD.
These are all fairly common uses of the word ACID, and thus should be reflected in the article.
I think that the above comment is outdated (as there is an "acid" and not "ACID" disambugation page).  Someone please confirm this.
you mean "Acid", this one is about chemicals I think everything's ok as it is..
I agree with the last statement, leave it as it is. When you see uppercase letters in a dictionary or encyclopedia, it means it is an acronym and it stands for something else. I think it is in the correct context.
:* I agree. A disambiguation page should not contain detailed info on one definition.<BR>Most of the contents of this page should be moved to ACID (database).
:::—gorgan_almighty 13:24, 8 December 2005 (UTC)
replies: text: This is not the disambiguation page.  acid and ACID are two completely different articles.  Wikipedia is case sensitive.  If a user types ACID in all caps, it is most likely that the user is looking for this page. -- kainaw™ 13:24, 14 January 2010 (UTC)
thread_title: Proposal

message: If I remember correctly the "Consistency" in ACID refers to the fact that the Database must ensure that the order of the queries must be consistent:
* Imagine a transacction A starts on time T
* Another unrelated query B starts at T+1
* If the unrelated query B tries to access some of the values beign modified by the A transaction, the database will wait till the transaction to finish, and give the data modified to the B query. If fact, modern databases will run the B query,  wait for A, if A affects data readed by B, rollback B and repeat that query again.
* The result is that if B goes after A, the operations will be always the same, no mather if B was in T+1 when the trasaction A was still running or T+200. The virtual time for all the modifications that the transaction A makes is T, so any T+1 query will see that modifications in place.
The article mentions consistency as "beign compliant with the constraints of the DB". Of course it is!. Constraints of the DB are unrelated with transactions! And of course transactions could not break them!
:That is not true.  Consistency has nothing to do with the order of transactions.  It has to do with the consistency of the database.  A "consistent state" is a state in which the rules of the database, such as field values, foreign keys, and the like, are all met.  So, if I interleave two transactions and have them run at the same time, the end result is consistent if and only if the database is in a consistent state when each transaction commits. It is not required that it be in an identical state that would result from running one transaction before the other transaction. -- kainaw™ 20:45, 26 February 2009 (UTC)
replies: text: I believe this part can be dropped, the person making the first comment did not quite know what he was talking about in the first place. Transactions are of course related to constraints and of course transactions can break constraints (in some DBMS's) and that is why ACID is not guaranteed in every case, and that is why it was defined and required to be enforced.  Yourbane (talk) 11:45, 19 August 2011 (UTC)
thread_title: Consistency

message: "... it may have used up its allocated CPU time." - This doesn't seem to make too much sense. CPU time is not allocated, it's used on demand. - intgr 05:09, 18 September 2005 (UTC)
replies: text: You're assuming a computer/OS can't be designed in a way that does allocate time in that way. You can imagine a company building a renderfarm and rents out computer time that would take advantage of something like that. For a real world example, the wolfram integrator (http://integrals.wolfram.com/index.jsp) is designed to timeout if it performs an integral that takes too long. Just replace the integrator with something that uses transactions and it makes sense. TomJF 04:58, 25 December 2005 (UTC)
replies: text:  Correct me if I'm wrong but this is another 'Implementation' discussion, which I believe has no place in a principle /axiom article, cleanup ? Yourbane (talk) 11:44, 19 August 2011 (UTC)
thread_title: Allocated CPU time

message: I subst'd the disambig link and changed it to point directly to the disambig. Figured I should mention it here. - CorbinSimpson 18:02, 29 January 2006 (UTC)
thread_title:  Disambig 

message: I have removed the following sentence altogether:
It is difficult to guarantee ACID properties in a network environment. Network connections might fail, or two users might want to use the same part of the database at the same time.
It is definitely a complex matter to implement transactions in a DBMS. If database queries are arriving via a network, or via applications running on the same computer, makes little fundamental difference. I wonder if the original author was thinking of distributed or replicated data. The following sentence mentioned two phase commit would suggest that. If so, the sentence should talk about distributed data, not a vague "network environment". If my assumption is correct, it would be better to expand the discussion of two phase commit a little rather than bring back the sentence I've deleted.
Paul Foxworthy (talk) 03:54, 27 September 2009 (UTC)
replies: text: Correct.  I wrote that after working on information for federated databases.  By "network environment", I am not referring to a single database with network capabilities.  I am referring to a "database" spread over a network in multiple repositories. -- kainaw™ 11:45, 27 September 2009 (UTC)
replies: text: I re-added and hopefully clarified the statement so that it's not ambiguous anymore. It's an quick introduction to distributed transactions so I personally find it appropriate. Does this sound good to you? -- intgr [talk] 12:51, 28 September 2009 (UTC)
replies: text:  Two phase commit is not sufhichent to solve this problime. See Two_Generals'_Problem and Byzantine_fault_tolerance. It is my understanding the the only way for more then one node to agree on a state is the Paxos_algorithm thou there are ways even in a distributed environment use a single nodes to get simmeler effects. For instance you could put transaction numbers on all your records keeping one copy of the record for each transaction then have a single node that tracks the current transaction. In this way you can atomically update the data on all nodes ( if operations are ordered correctly ) with out the need for distrubeted consensus. Sorta MVCC for clusters. ( Sorry about the spelling. Spell check in google chorme sucks and so dose my spelling.)Wikiwikimoore (talk) 22:03, 11 January 2010 (UTC)
replies: text: You are drifting from distributed databases to distributed database administration.  Two-phase commit handles the problem of having one transaction commit while another is attempting to commit and causing a problem.  It has nothing to do with how the administration is structured.  It could be a single centralized administration that gives permission to commit to one transaction at a time.  If you go into distributed administration, then you need to figure out how to manage who can commit and when.  Quorum is a simple solution to the problem which is rather fault tolerant - and it even handles the Byzantine problem if the consensus is higher than 1. -- kainaw™ 05:24, 12 January 2010 (UTC)
replies: text:  Would it not be reasonable to drop all information related to "two-phase commit" as it's merely one solution enabling ACID, rather than a principle inherent to ACID ?  Looks to me as specialized as the information on 'this dbms' or 'that dbms' or WAL or ... Implementations are interesting but overall irrelevant to the ACID principles. Yourbane (talk) 11:39, 19 August 2011 (UTC)
thread_title:  Network environment 

message: "One implementation relaxes the isolation property..."  Does it really?  From reading the page on snapshot isolation, it sounds as if the isolation requirement is not loosened at all.  Snapshot isolation is just a means of implementing isolation without forcing total serialization.  —Preceding unsigned comment added by 24.238.213.117 (talk) 19:26, 3 June 2010 (UTC)
thread_title:  Relaxing the isolation property? 

message: The article states that:
In the previous example, one rule was a requirement that A + B = 100; most database systems would not allow such a rule to be specified, and so would have no responsibility to enforce it.
This is not true.  While MySQL cannot enforce check constraints, PostgreSQL, Oracle Database, and Microsoft SQL Server all can.  Under PostgreSQL, with the following table definition:
CREATE TABLE acidtest (A INTEGER, B INTEGER CONSTRAINT sum CHECK (A + B = 100));
attempting to insert a row in violation of the A + B = 100 constraint results in an error:
 INSERT INTO acidtest VALUES (10, 10);
 ERROR:  new row for relation "acidtest" violates check constraint "sum"
What should be done with this statement in the article?  DRAGON 280  (TALK/CONTRIBS) 12:43, 30 March 2011 (UTC)
replies: text: I suggest going back to a much earlier version that explains how that validation rule is either met or the update is reverted. Right now, someone has decided that it is more important to express limited knowledge of databases than to explain the concepts of ACID. -- kainaw™ 12:49, 30 March 2011 (UTC)
replies: text: I've restored the content in "Consistency failure" before [ this edit].  I'll clean it up later.  DRAGON 280  (TALK/CONTRIBS) 17:32, 30 March 2011 (UTC)

text: Even SQLite honors the check constraint:
sqlite> CREATE TABLE acidtest (A INTEGER, B INTEGER CHECK (A + B = 100));
sqlite> INSERT INTO acidtest VALUES (10, 10);
Error: constraint failed
 DRAGON 280  (TALK/CONTRIBS) 17:59, 30 March 2011 (UTC)
thread_title:  Integrity constraint enforcement 

message: The term write ahead logging is used, but pre image logging is described. WAL writes the new (changed) data to a logfile which is copied to the database after the last previous read transaction ends.  — Preceding unsigned comment added by 212.152.157.50 (talk) 07:43, 25 January 2013 (UTC)
thread_title:  Write ahead logging 

message: The main page gives this example:
CREATE TABLE acidtest (A INTEGER, B INTEGER CHECK (A + B = 100));
and says that if 10 is subtracted from A, then at that point the check constraint is false. As there is no comma in the example before the word CHECK, the constraint is a column constraint, and I don't believe it's legal to reference another column. (The example doesn't reference any SQL standard.) If a comma is inserted, it becomes a table constraint, and therefore any attempt to change A without also changing B would fail. Therefore, I don't think the example illustrates what it was intended to. To my knowledge, check constraints are always in force (unless something is done to turn them off), and I don't think transaction management of any kind is required to help them do their job. Rochkind (talk) 16:16, 9 May 2013 (UTC)
thread_title:  Error in example? 

message: Seems like this tree is a bush--an article about 'transactions' could also reference 'structure'. Both ACID and Database normalization seem to be on par meta-concepts. 
Xtian~enwiki (talk) 19:04, 14 April 2020 (UTC)
thread_title:  See Also suggestion