tags:

views:

199

answers:

2

Hi, I was just reading about RDBMS, and one property of an RDBMS is atomicity. So, if money is withdrawn from an account and transferred to another, either the transaction will happen completely or not at all. There are no partial transactions. But how is actually ensured?

Sql queries for the above scenario might look like (i) UPDATE accounts set balance = balance - amount WHERE ac_num = 101 (ii) UPDATE accounts set balance = balance + amount WHERE ac_num = 102

Which by no means ensures atomicity.. So how does it actually happen?

+4  A: 

If you do

BEGIN TRANSACTION
UPDATE accounts set balance = balance - amount WHERE ac_num = 101
UPDATE accounts set balance = balance + amount WHERE ac_num = 102
COMMIT TRANSACTION

The database system will write notes to what is has done for changes on account 101. And then if the work on account 102 would fail, the RDBMS uses those notes to undo the work on 101.

Furthermore, when it has started work on account 101 is takes a lock on the database, so that no-one else can come and read the updated, but not committed data in account 101. (A lock here is basically just a note somewhere "I am working here, do not touch.")

leiflundgren
No, it does not lock the database. Depending on the transaction isolation mode, typically other people reading the database will not see the updates before they are committed (they will see the previous values).
MarkR
Yes it does, depending on the transaction isolation mode. In modern RDBMS:s locking happens on row level.This "previous values" thing can result in unrepeatable read anomalies.
abababa22
+1  A: 

To be atomic, transactions need to:

  • Prevent other transactions from interfering with the rows they are writing or reading
  • Make sure that either all or none of the changes that the transaction makes, will be in the database when the transaction commits.

First one is achieved by locking rows that the transaction reads or writes during it's execution.

Second one is done so that transactions write their actions into a transaction log. This makes the database able to recover even when the server loses power during a transaction. In this case the recovery process will read the log, make sure that active (uncommited) transactions get aborted and changes made by them are canceled.

abababa22