Transactions allow multiple database operations to be grouped together into a single unit of work that can be committed or rolled back together to maintain data integrity. They guarantee properties such as atomicity, consistency, isolation, and durability (ACID). Transaction support is provided by relational databases, content management systems, versioning systems, and file systems. Transactions ensure that the database remains in a consistent state regardless of system failures or concurrent operations.

1. TRANSACTIONS
Talk 9

2. TRANSACTIONS: WHAT FOR?
• Allow
many operations to be canceled at once.
• Maintain
• Handle
consistency of data.
concurrent requests in a deterministic way.
• Guarantee
the persistence of data.

3. TRANSACTIONS: WHAT FOR?
• RDBMS
• Any
Content Management System
• Versioning
• Filesystems
Systems (Git, SVN)
(NTFS, HFS, ext3, ext4, BTRfs)

4. TRANSACTIONS: WHAT FOR?
•A
unit of work.
•SQL
is inherently transactional.

5. TRANSACTIONS: WHAT FOR?
•Atomicity.
•Consistency.
•Isolation.
•Durability.

6. TRANSACTIONS: WHAT FOR?
•Atomicity: every SQL command is transactional.
•Consistency: not only relational but also logical.
•Isolation: not necessarily serialized.
•Durability: resist to system failures.
http://en.wikipedia.org/wiki/ACID

7. ATOMICITY
• The
• All
transaction is one or nothing.
its modifications are applied, or none.
• Transactionless
means: each statement has its own
transaction (= autocommit).

8. CONSISTENCY
• Transactions
leave the database in a consistent state: all its
internal rules are always enforced.
• The
DBMS handles relational consistency, the developer
handles logical consistency.

9. DURABILITY
• Your
data is safe.
• Eg: non
persisted data is logged.

10. ISOLATION
• How
the DBMS handles concurrent accesses to data?
• Many
levels of isolation.
isolation causes read phenomena (reading nonexistent data, writing ephemeral data).
• Wrong

11. READ PHENOMENA
users
id
name
age
1
Joe
20
2
Jill
25
http://en.wikipedia.org/wiki/Isolation_(database_systems)

12. id
1
2
users
name
Joe
Jill
age
20
25
Transaction 1
DIRTY READS
Transaction 2
SELECT age FROM users WHERE id = 1;!
/* will read 20 */
UPDATE users SET age = 21 WHERE id = 1;!
/* No commit here */
SELECT age FROM users WHERE id = 1;!
/* will read 21 */
ROLLBACK; /* lock-based DIRTY READ */

13. id
1
2
users
name
Joe
Jill
age
20
25
NON-REPEATABLE
READS
Transaction 1
Transaction 2
SELECT * FROM users WHERE id = 1;
UPDATE users SET age = 21 WHERE id = 1;!
COMMIT;
SELECT * FROM users WHERE id = 1;!
COMMIT; /* lock-based REPEATABLE READ */

14. id
1
2
users
name
Joe
Jill
age
20
25
Transaction 1
PHANTOM READS
Transaction 2
SELECT * FROM users!
WHERE age BETWEEN 10 AND 30;
INSERT INTO users VALUES ( 3, 'Bob', 27 );!
COMMIT;
SELECT * FROM users!
WHERE age BETWEEN 10 AND 30;!
// Will see Bob.

15. ISOLATION LEVELS AND
READ PHENOMENA
Isolation level
Read
Uncommitted
Read
Committed
Repeatable
Read
Serializable
Dirty reads
may occur
Non-repeatable
Phantom reads
reads
may occur
may occur
may occur
may occur
may occur

16. DBMS AND
ISOLATION LEVELS
Isolation level
Oracle
Firebird
Apache Derby
MS SQL
MySQL
Read
Uncommitted
NO
NO
OK
OK
OK
Read
Committed
Default
Default
Default
Default
OK
Repeatable
Read
Not exactly
OK
OK
OK
Default
Serializable
OK
OK
OK
OK
OK
Note: no-one defaults to Serializable!!

17. THE DELPHI WAY
...!
Connection1.StartTransaction;!
try!
...!
Query1.ExecSQL;!
...!
Connection1.Commit;!
except!
Connection1.Rollback;!
raise;!
end;!
...
http://docwiki.embarcadero.com/RADStudio/XE5/en/Managing_Transactions_(FireDAC)

18. THE BBOX WAY
Windows
Client
Controllers
BOs
Server
DAOs
Database

19. THE BBOX WAY
Windows
Controllers
@Transactional
BOs
DAOs
Database

20. THE SPRING WAY
@Transactional!
public void doATransactionalThing() {!
...

21. THE SPRING WAY
@Transactional(!
isolation = Isolation.SERIALIZABLE,!
rollbackFor = {KaBoomException.class},!
propagation = Propagation.REQUIRED,!
readOnly = true)!
public void doATransactionalThing()!
throws KaBoomException {!
...

22. Next Talk: Data Caching