DB Concurrency ITEC 340 Database I Dr. Ian Barland (and, access privileges) ITEC 340 Database I Dr. Ian Barland based on notes by Dr. Pittges, Dr. Phillips

Allowing Multi-user Access GRANT select on Students to fred; GRANT select, insert ON Customers to ALL; GRANT ALL on Customers to fred; CREATE ROLE manager_privs; GRANT select, insert, update ON Customers TO manager_privs; GRANT manger_privs TO amy, bob, fred;

grant syntax Grant Revoke Very effective when used with views GRANT <objPriv> ON <object> TO <user> GRANT <sysPriv> ANY TABLE TO <user> <user> can also be PUBLIC, or a role <objPriv> can be ALL <sysPriv> includes all <objPrivs> plus CREATE Revoke REVOKE <objpriv> ON <object> FROM <user> REVOKE <syspriv> FROM <user> Very effective when used with views

Oracle Object Privs ALTER DELETE EXECUTE INDEX INSERT SELECT UPDATE ALL

Problems with Concurrent Access Lost updates Uncommitted Data Inconsistent retrievals Solution Resource Locking: While a user (transaction) holds a lock, no other user can access that resource.

Locking Granularity lock entire database lock one table lock one page Not efficient lock one table Sometimes needed for batch updates Not very efficient lock one page Usually contains multiple rows Locks a unit corresponding to a the working unit of the OS lock one row Most commonly used locking level Very efficient lock one column Locks only certain attributes of a row.

How to specify locking in Oracle Table Lock Command the 'FOR UPDATE' option of SELECT command: Select * From Customer Where CustID = '123456' For update; -- If I can't get lock, keep waiting until I can (“block”) Select * From Customer Where CustID = '123456' For update WAIT 5; -- Try to get lock for 5sec, before throw exception. Select * From Customer Where CustID = '123456' For update NOWAIT; -- If I can’t get lock, immediately throw exception.

Lock Types and Strategies Exclusive vs. Shared Locks (lock type) Exclusive Will not allow another transaction to obtain a lock of any kind. Shared Allows multiple transactions to read the data. Will not allow any other transaction to write the locked rows. Can potentially be upgraded to an exclusive lock Optimistic vs. Pessimistic Locking (locking strategy) Pessimistic (“lock, ‘cause somebody’s almost surely going to interfere”) Rows are locked at point of client retrieval of data Client application will not proceed if locks cannot be obtained Locks are not released until client application submits completed transaction Optimistic (“nobody's likely to interfere w/ me, so minimize locking”) No locking occurs until the transaction is ready for submission by the client program Can use several techniques to avoid business rule violations Check row image before updating (timestamp, sequence number, or compare fields) Update only changed fields Use incremental updates to balances Use conditional transactions with a timer Client refreshes (not typically an option on web applications)

Pessimistic Locking Strategy Steps Request Lock(s) Retry (wait) or Abort Lock(s) Acquired Read ABORT/rollback Ponder Update Commit/Release Lock(s)

Optimistic Locking Strategy Steps Read Ponder Request Lock(s) Retry (wait) or Abort Lock(s) Acquired ABORT/rollback Check for Mutation Mutation Detected Update * * update should include update to timestamp or mutation sequence number. Commit/Release Lock(s)

Transactions Transaction Definition: Example: A logical unit of work that consists of one or more SQL statements that moves the database from one consistent state to another consistent state. Therefore, the transaction must succeed or fail as a unit. Example: 01/01/02 Journal Entry #87543 110 Accounts Receivable – R. Smith(123) 1,045 401 Service Revenue – tax services 645 402 Service Revenue – consulting services 400 (provided services on account) Would cause multiple related inserts and updates

Oracle: No Transaction Defined Begin Update accounts set balance = balance + 1045 where accountnum = ‘110’; Commit; Update accounts set balance = balance + 645 where accountnum = ‘401’; Update accounts set balance = balance + 400 where accountnum = ‘402’; Update customers set BalDue = BalDue + 1045 where custid = 123; Insert into JournalEntries (JENumber, JEDate, Description) values (87543, ‘01-JAN-02’, ‘provided services on account’); Insert into DrCrDetail (JENumber, LineNumber, Account, Amount) values (87543, 1, ‘110’, 1045.00); values (87543, 2, ‘401’, 645.00); values (87543, 3, ‘402’, 400.00); End; General guide: Commit as soon as you can (but no sooner).

Transaction Methods (Oracle) BEGIN [transactName] is optional. COMMIT [TRAN[SACTION] transactName] saves the changes and ends the current transaction. SAVEPOINT [savepointName] optional, creates a point that can be rolled back to ROLLBACK [TO savepointName] ends the current transaction and restores the databases in the Workspace object to the state they were in when the current transaction began. The transactName is ignored – it’s purely for readability in nested commits.

Transaction Methods (Oracle with lock waits) Begin Begin Transaction; Update accounts set balance = balance + 1045 where accountnum = ‘110’; Update accounts set balance = balance + 645 where accountnum = ‘401’; Update accounts set balance = balance + 400 where accountnum = ‘402’; Update customers set BalDue = BalDue + 1045 where custid = 123; Insert into JournalEntries (JENumber, JEDate, Description) values (87543, ‘01-JAN-02’, ‘provided services on account’); Insert into DrCrDetail(JENumber, LineNumber, Account, Amount) values (87543, 1, ‘110’, 1045.00); Insert into DrCrDetail (JENumber, LineNumber, Account, Amount) values (87543, 2, ‘401’, 645.00); values (87543, 3, ‘402’, 400.00); Commit; Exception rollback; End;

Transaction/Locking Problem Deadlock Solutions Prevention e.g.: Two-phase locking with nowait Dectection Detect, then kill and rollback one transaction

Transaction Methods (Oracle with 2 stage locking) Begin Begin Transaction; Select * from accounts where accountnum in (‘110’, ‘401’, ‘402’) for update nowait; Select * from customers where custid = 123 for update nowait; Update accounts set balance = balance + 1045 where accountnum = ‘110’; Update accounts set balance = balance + 645 where accountnum = ‘401’; Update accounts set balance = balance + 400 where accountnum = ‘402’; Update customers set BalDue = BalDue + 1045 where custid = 123; Insert into JournalEntries (JENumber, JEDate, Description) values (87543, ‘01-JAN-02’, ‘provided services on account’); Insert into DrCrDetail(JENumber, LineNumber, Account, Amount) values (87543, 1, ‘110’, 1045.00); Insert into DrCrDetail (JENumber, LineNumber, Account, Amount) values (87543, 2, ‘401’, 645.00); values (87543, 3, ‘402’, 400.00); Commit; Exception rollback; End;

SELECT FOR UPDATE WAIT <seconds> Begin Begin Transaction; Select * from accounts where accountnum in (‘110’, ‘401’, ‘402’) for update wait 3; Select * from customers where custid = 123 for update wait 3; Update accounts set balance = balance + 1045 where accountnum = ‘110’; Update accounts set balance = balance + 645 where accountnum = ‘401’; Update accounts set balance = balance + 400 where accountnum = ‘402’; Update customers set BalDue = BalDue + 1045 where custid = 123; Insert into JournalEntries (JENumber, JEDate, Description) values (87543, ‘01-JAN-02’, ‘provided services on account’); Insert into DrCrDetail(JENumber, LineNumber, Account, Amount) values (87543, 1, ‘110’, 1045.00); Insert into DrCrDetail (JENumber, LineNumber, Account, Amount) values (87543, 2, ‘401’, 645.00); values (87543, 3, ‘402’, 400.00); Commit; Exception rollback; End;