Talk:Atomicity (database systems)
|WikiProject Databases / Computer science||(Rated Start-class, High-importance)|
|WikiProject Systems||(Rated Disambig-class, Mid-importance)|
22 December 2006
The interface between database and programming environment may reintroduce problems that a programmer might naively expect atomic transactions to do away with. For instance, if an operation fails in a transaction, it is often the programmer's responsibility to detect that failure and manually roll back the transaction before retrying. Not doing so will result in a partially-completed transaction!
This was removed by DanPope. I think this text is an important point, but I'm not going to re-add it without support. (I put it there in the first place.) Is there a good place to put it in the article? Somewhere else to put it? --Chris Purcell 12:41, 22 December 2006 (UTC)
Removed unsubstantiated statement that did not seem to be relevant in context
I removed the statement: "This is the main advantage of database over the file system" mainly because it appeared in an example of atomicity. Even if it is entirely true, it belongs in an area where the relative merits of the two items are being presented, not as part of a nuetral definition of atomicity. — Preceding unsigned comment added by Freshbaked (talk • contribs) 18:58, 12 December 2011 (UTC)
As a consequence, the transaction cannot be observed to be in progress by another database client. At one moment in time, it has not yet happened, and at the next it has already occurred in whole (or nothing happened if the transaction was cancelled in progress).
Is this correct? This statement seems to imply at least isolation as well (first part of the explanation is correct). It is also stronger than what is described in the ACID article.
Atomicity just seems to imply that I can observe partial transactions, but any partial transaction I observe will not be aborted.