09 Transactions

Post on 17-May-2015

184 views 0 download

Tags:

Transcript of 09 Transactions

TRANSACTIONSTalk 9

TRANSACTIONS: WHAT FOR?

• Allow many operations to be canceled at once.

• Maintain consistency of data.

• Handle concurrent requests in a deterministic way.

• Guarantee the persistence of data.

TRANSACTIONS: WHAT FOR?

• RDBMS

• Any Content Management System

• Versioning Systems (Git, SVN)

• Filesystems (NTFS, HFS, ext3, ext4, BTRfs)

TRANSACTIONS: WHAT FOR?

•A unit of work. •SQL is inherently transactional.

TRANSACTIONS: WHAT FOR?

•Atomicity. •Consistency. •Isolation. •Durability.

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

ATOMICITY

• The transaction is one or nothing.

• All its modifications are applied, or none.

• Transactionless means: each statement has its own transaction (= autocommit).

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.

DURABILITY

• Your data is safe.

• Eg: non persisted data is logged.

ISOLATION

• How the DBMS handles concurrent accesses to data?

• Many levels of isolation.

• Wrong isolation causes read phenomena (reading non-existent data, writing ephemeral data).

READ PHENOMENA

users

id name age1 Joe 202 Jill 25

http://en.wikipedia.org/wiki/Isolation_(database_systems)

DIRTY READSusers

id name age1 Joe 202 Jill 25

Transaction 1 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 */

NON-REPEATABLE READS

usersid name age1 Joe 202 Jill 25

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 */

PHANTOM READSusers

id name age1 Joe 202 Jill 25

Transaction 1 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.

ISOLATION LEVELS AND READ PHENOMENA

Isolation level Dirty reads Non-repeatable reads Phantom reads

Read Uncommitted may occur may occur may occur

Read Committed may occur may occur

Repeatable Read may occur

Serializable

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!!

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)

THE BBOX WAY

Database

DAOs

BOs

Controllers

Windows

Server

Client

THE BBOX WAY

Database

DAOs

BOs

Controllers

Windows

@Transactional

THE SPRING WAY

@Transactional!public void doATransactionalThing() {! ...

THE SPRING WAY

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

Next Talk: Data Caching