© D. Wong Persistent, Stored Modules (PSM) (Ref. 8.2 )  A way to create and store procedures or functions with a database schema  The procedure/functions can be used in SQL queries or other SQL statements to perform within the database computations that cannot be expressed in SQL query language  Like a simple, general-purpose language  SQL/PSM standard (PSM-96). Commercial DBMS offers such capabilities with variations (e.g. Oracle, MS SQL)

© D. Wong PSM Modules  Collection of function and procedure definitions, temporary relation declarations, and other declarations. (PSM modules in Oracle are Packages)  Parameters: mode-name-type triples  Modes: IN, OUT, INOUT PSM Procedure PSM Function CREATE PROCEDURE (parameters) local declarations local declarations procedure body; procedure body; CREATE FUNCTION (parameters) return return local declarations local declarations procedure body; procedure body;

© D. Wong Statement Forms in PSM 1. CALL –statement (for procedures only) CALL ( ); i.From a host-language program: e.g. EXEC SQL CALL proc(:x, 3); // x is a shared variable ii.As a statement of another PSM function or procedure iii.As an SQL command in an SQL client (e.g. SQLPLUS). E.g CALL proc (1, 3)

© D. Wong Statement Forms in PSM (continued) 2. RETURN statement (for functions only) 3. Declaration of local variables (precede executable statements): DECLARE ; 4. Assignment statement: SET = ; 5. Statement group in BEGIN … END block 6. Statement label - labelName: 7. Branching statement (ref. Fig. 8.9, 8.10 )

© D. Wong Statement Forms in PSM (continued 2) 8. Queries (select-from-where): 9. Loops a)LOOP END LOOP; b)Only to iterate over a cursor: FOR AS CURSOR FOR DO END FOR c)WHILE DO END WHILE; d)REPEAT UNTIL END REPEAT;

© D. Wong PL/SQL of Oracle  Oracle’s procedural language (PL). It’s a superset of SQL.  Used to create stored procedures/functions and packages, to trigger database events, or to add programming logic to SQL commands  Ref. : Ullman and students’s introduction

© D. Wong Call-level Interface (CLI)  The application is written entirely in the host language.  SQL statements are the values of string variables constructed at run time  The string variables are passed as arguments to host language procedures provided by the CLI library of functions.  No special syntax, no pre-compiler is needed.  System independence – in principle!  SQL 99's CLI standard is an adaptation of ODBC (Open Database Connectivity) and the host language is C  SQL/CLI in Java is JDBC (discussed in week 9)

© D. Wong The SQL Environment  It's the framework in which data may exist and SQL operations on data may be executed. I.e. a DBMS running at an installation.  SQL standard of elements hierarchy: Fig nd ed 1.Schema – collection of tables, views, assertions, triggers, PSM, modules, etc. 2.Catalogs – collections of schemas 3.Clusters – collections of catalogs. Each user has an associated cluster.

© D. Wong The SQL Environment (continued)  SQL clients and servers – processes that runs of the same or different hosts. –Server : support operations on database elements –Client : allow a user to connect to a server and operate on a database (e.g. SQLPLUS)  Connection – a "connection" must be made between the server and the client by executing the CONNECT statement on the client host. Default connection is made by an SQL client (e.g. SQLPLUS).  Session – SQL operations that are performed while a connection is active. Each session has a current catalog, schema, and an authorized user. Reminder: temporary elements such as view exists only within the environment of a session.

© D. Wong The SQL Environment (continued 2)  Modules –An SQL term for an application program –3 kinds of modules in SQL standard: 1. Generic SQL interface, e.g. SQLPLUS 2. Embedded SQL 3. True modules, e.g. PSM –SQL agent – a SQL module in execution Ref. Fig pp. 384

© D. Wong  SQL Transactions –Example in JDBC  Security and User Authorization in SQL  Object Oriented Model –ODL –OQL  Object Relational Systems  Recursion in SQL

© D. Wong Transactions in SQL ( nd ed.)  Concerns with enforcing the ACID properties of transactions  Review: ACID properties of “proper” execution: –Atomicity : All of the updates of a transaction are successful, or no update take place –Consistency: Each transaction should leave the database in a consistent state –Isolation: Each transaction, when executed concurrently with other transactions, should have the same effect as if it had been executed by itself (serializable behavior) –Durability: Once a transaction has completed successfully, its changes to the database should be permanent. Even serious failures should not affect the permanence of a transaction.

© D. Wong Serializability and Atomicity  Serializable function execution: If the function executions behave as if they were run serially, even though their execution may overlap in time.  Example of problem with concurrent function executions that are not serialized: Ex. 8.26, Fig and Fig pp. 398  Example of problem when failure (system, network, power) occurs during a database operation: Ex. 8.27, Fig pp. 400

© D. Wong Transactions  To solve the serializability and atomicity problem.  Def.: A collection of one or more operations on the database that must be executed atomically, (i.e. either all are done or none are) and in a serializable manner (i.e. isolation).  End of a SQL transaction is marked by either operations: 1.COMMIT - the database will be permanently updated 2.ROLLBACK – no changes by the transaction appear in the database (abort the transaction)

© D. Wong Transactions (continued)  In query interface (e.g. SQLPLUS): Transactions are single queries or modification statements.  In program interface (e.g. JDBC): 1.Single SQL statement: use automatic commit mode. A transaction:  starts when the statement begins execution  ends when an automatic commit or rollback is completed 2.More than 1 SQL statement: – Disable auto-commit – After all SQL statements in a transaction are executed, call commit; or rollback if error occurs

© D. Wong Deferred constraints  When the commit method is executed, if there are deferred constraints that need to be checked, and these constraints are now violated, then the transaction is not committed.  Instead, the transaction is rolled back and the error is reported via the SQLSTATE variable.  In JDBC, this SQLSTATE is reported via the SQLException object's getSQLState() method.

© D. Wong Code segment to show transaction control in JDBC: try { //... add code here for making connection... PreparedStatement updateSales = con.prepareStatement("update COFFEES " + "set SALES = ? where COF_NAME like ?"); PreparedStatement updateTotal = con.prepareStatement( "update COFFEES " + "set TOTAL = TOTAL + ? where COF_NAME like ?") ; con.setAutoCommit(false); updateSales.setInt(1, 50);updateSales.setString(2, "Colombian"); updateSales.executeUpdate();// first update updateTotal.setInt(1, 50);updateTotal.setString(2, "Colombian"); updateTotal.executeUpdate();// second update con.commit(); con.setAutoCommit(true); } catch(SQLException ex) { if (con != null) { try { System.err.print("Error detected! Transaction is being rolled back!"); con.rollback(); } catch(SQLException excep) { System.err.print("SQLException: " + excep.getMessage()); } } // end if there is a connection }

© D. Wong Transaction Isolation Levels  Determine whether and how a transaction will be affected by concurrent transactions – transactions from different SQL sessions that are accessing the same data.  SQL isolation levels are to address: 1.Dirty Read: a read of dirty data. Dirty data is data written by a transaction that has not yet committed. 2.Non-repeatable Read: One transaction reads a row. Another deletes or modifies it and COMMIT before the first one does. Now, if the first transaction perform the same read again will get different result. 3.Phantom tuples: tuples that are inserted into the database by another transaction while one's transaction is running.

© D. Wong Isolation levels in JDBC   The 5 isolation levels: 1. TRANSACTION_NONE - transactions not supported (This level is not in the SQL standard) 2. TRANSACTION_READ_UNCOMMITTED - allows dirty reads, nonrepeatable reads, and phantom reads 3. TRANSACTION_READ_COMMITTED - prevents dirty reads, but does not prevent nonrepeatable reads, and phantom reads 4. TRANSACTION_REPEATABLE_READ - disallow dirty reads, nonrepeatable reads, but allow phantom reads 5. TRANSACTION_SERIALIZABLE - disallow dirty reads, nonrepeatable reads, and phantom reads (The highest level, the default)  Connection methods to get and set them: 1.getTransactionIsolation() - to find out the transaction isolation level the database is set 2.setTransactionIsolation() - to set the appropriate isolation level

© D. Wong Choosing Isolation Levels  A choice of compromise between performance and a slightly inconsistent view of data (because data is being updated concurrently by other users).  Ref. Ex. 8.32, 8.33 pp. 408

© D. Wong DBMS Techniques to enforce ACID  Locking – granularity of locks is important. Locks are obtained at the beginning of a transaction. Locks are released at the end of commit or rollback.  Logging – write a log to nonvolatile storage. Assure durability.  Transaction Commitment – for durability and atomicity, transactions are computed “tentatively”, recorded, but no changes are made to the db until the transaction gets committed. Changes are copied to the log, then copied to db.

© D. Wong J2EE Transaction Management in Enterprise JavaBeans (EJBs) Ref. JavaTM 2 Enterprise Edition Developer's Guide

© D. Wong Container-Managed Transactions (see note page of this slide) Description Code does not include statements that begin and end the transaction Immediately before an EJB method starts - transaction begins Just before the method exits - commits Each method can be associated with a single transaction Prohibited methods, e.g.: commit, setAutoCommit, and rollback methods of java.sql.Connection Limitation: When a method is executing, it can be associated with either a single transaction or no transaction at all

© D. Wong Bean Managed Transaction (see note page of this slide) Session bean code invokes methods that mark the boundaries of the transaction - setAutoCommit(); commit(); rollback(); An entity bean may not have bean-managed transactions public void ship (String productId, String orderId, int quantity) { try { con.setAutoCommit(false); updateOrderItem(productId, orderId); updateInventory(productId, quantity); con.commit(); } catch (Exception ex) { try { con.rollback(); throw new EJBException("Transaction failed: " + ex.getMessage()); } catch (SQLException sqx) { throw new EJBException("Rollback failed: " + sqx.getMessage()); } } } Ref. Java TM 2 Enterprise Edition Developer's Guide, JDBC Transaction Example: