RDBMS Transaction Isolation Levels

Size: px

Start display at page:

Download "RDBMS Transaction Isolation Levels"

Agnes Willis
5 years ago
Views:

1 Optimistic Locking

2 RDBMS Transaction Isolation Levels Read Uncommitted Dirty reads are allowed, so one transaction may see not-yetcommitted changes made by other transactions Read Committed Non-repeatable reads phenomenon CAN occur (SELECT single record may return different values) Repeatable Reads Phantom reads CAN occur ( SELECT COUNT(*)... returns different results) Serializable Perfect Or maybe not... Concurrent work is very slow, high probability of deadlocks Optimistic Locking 2

3 Default Transaction Isolation Level Both Repeatable Read and Serializable are too expensive most of the time Concurrent work is practically impossible (either too slow or too many deadlocks) All RDBMS by default set Read Committed transaction isolation level But sometimes we want to have Repeatable Read semantics temporarily Sometimes in request type use-cases Practically always in conversation type use-cases Optimistic Locking 3

4 Optimistic Locking 4

5 The Problem Read Committed isolation level is not sufficient to guarantee data consistency But it has sufficiently good DB performance profile Repeatable Reads isolation level solves most data consistency problems But DB performance (transaction throughput, to tell exactly), suffers Optimistic Locking 5

6 Solution: Optimistic Locking Each table must have additional column storing version information (a number) Corresponding field of JPA entity must be marked By default LockModeType.OPTIMISTIC is being used No manual work is needed by programmer Combined with Read Committed isolation level solves most data consistency problems LockModeType.OPTIMISTIC_FORCE_INCREMENT may be used additionally to prevent Phantom Reads phenomenon Practical examples with JPA: Optimistic Locking 6

7 EntityManager.find(entityClass, primarykey, LockModeType lockmode) EntityManager.lock(LockModeType lockmode) No lock mode version attributes are being checked only for entities that were updated The use of optimistic lock modes causes the persistence provider to check the version attributes: for entities that were read during a transaction, and were updated. The use of pessimistic lock modes requires JPA to immediately acquire long-term read or write locks for the database data corresponding to entity state. Optimistic Locking 7

8 @Version dažniausiai užtenka T1 Person p1 = em.find(person.class, id); T2 Person person2 = em.find(person.class, id); String name = p1.getname(); // name is "John" person2.setname("mike"); Transaction commits person2.setname(name + "y"); em.flush(); // OptimisticLockException Optimistic Locking 8

9 persistence/lockmodetype.html If transaction T1 calls for a lock of type LockModeType.OPTIMISTIC on a versioned object, the entity manager must ensure that neither of the following phenomena can occur: Dirty read: Transaction T1 modifies a row. Another transaction T2 then reads that row and obtains the modified value, before T1 has committed or rolled back. Transaction T2 eventually commits successfully. Non-repeatable read: Transaction T1 reads a row. Another transaction T2 then modifies or deletes that row, before T1 has committed. Both transactions eventually commit successfully. Calling a lock of type LockModeType.OPTIMISTIC_FORCE_INCREMENT on a versioned object, will also force an update (increment) to the entity's version column. Optimistic Locking 9

10 Kada neužtenka: T1 Person p1 = em.find(person.class, id); String name = p1.getname(); // name is "John" int count = em.createquery( "SELECT count(p) FROM Person p WHERE p.name='john'" ).getsingleresult(); T2 Person person2 = em.find(person.class, id); person2.setname("mike"); Transaction commits // count == 0 -> Non-repeatable read Optimistic Locking 10

11 Pataisymas: T1 Person p1 = em.find(person.class, id, LockModeType.OPTIMISTIC); T2 Person person2 = em.find(person.class, id); String name = p1.getname(); // name is "John" int count = em.createquery( "SELECT count(p) FROM Person p WHERE p.name='john'" ).getsingleresult(); --> OptimisticLockException person2.setname("mike"); Transaction commits Optimistic Locking 11

12 Kada net OPTIMISTIC nepakanka: T1 Person john1 = em.find(person.class, id); T2 Person john2 = em.find(person.class, id, LockModeType.OPTIMISTIC); //T1 doesn't know about John's new car. if (john1.getcars().size() > 0) john1.setlabel("john has a car"); else john1.setlabel("no car..."); // --> Rezultatas: "No car..." //John gets a mercedes: Car mercedes = new Car(); mercedes.setperson(john2); em.persist(mercedes); john2.getcars().add(mercedes); Transaction commits Optimistic Locking 12

13 OPTIMISTIC_FORCE_INCREMENT T1 Person john1 = em.find(person.class, id); T2 Person john2 = em.find(person.class, id, LockModeType. OPTIMISTIC_FORCE_INCREMENT); //T1 doesn't know about John's new car. if (john1.getcars().size() > 0) john1.setlabel("john has a car"); else john1.setlabel("no car..."); // --> OptimisticLockException //John gets a mercedes: Car mercedes = new Car(); mercedes.setperson(john2); em.persist(mercedes); john2.getcars().add(mercedes); Transaction commits Optimistic Locking 13

14 Conclusions Using: Read Committed isolation level in DB, plus Optimistic locking in your application gives Repeatable Reads isolation level semantics without hindering DB transaction throughput With optimistic locking the faster transaction always wins Use pessimistic locking if that is not OK. Additional reading: Optimistic Locking 14

15 Recovering from OptimisticLockException From JPA specification: An OptimisticLockException always causes the transaction to be marked for rollback Transaction rollback causes all pre-existing managed instances to become detached Todėl klaidos apdorojimo kodas turi pradėti naują Optimistic Locking 15

CSE 530A ACID. Washington University Fall 2013

CSE 530A ACID. Washington University Fall 2013 CSE 530A ACID Washington University Fall 2013 Concurrency Enterprise-scale DBMSs are designed to host multiple databases and handle multiple concurrent connections Transactions are designed to enable Data