SQL in a Programming Environment - Part II CIS 4301 Lecture Notes Lecture 23 - 13/4/2006.

SQL in a Programming Environment - Part II CIS 4301

Lecture Notes

Lecture 23 - 13/4/2006

Lecture 23© CIS 4301 - Spring 2006 2

Application Development

Often important to execute parts of the application logic directly in process space of DBMS Why?

One solution: Programming Language for DBMS


DBMS Programming Language

Many DBMS's provide their own mini-programming language that includes SQL, variables, control constructs, procedures, etc. Simple, general-purpose language Smoothes over the discontinuity between the programming language and SQL

Runs in the DBMS Used to create procedures or functions to be stored with database schema A.k.a. Persistent Stored Modules PSM (SQL/PSM)

A.k.a. Stored Procedures


DBMS Programming Languages

E.g., Oracle’s Procedure Language SQL (PL/SQL) Primarily used for writing PSM’s and trigger actions

User can execute PL/SQL interactively (SQLPlus) or call it from host language programs

For rest of lecture, use SQL/PSM standard syntax


Persistent Stored Modules

In SQL speak, application program is called module Collections of functions and procedure definitions, temp. relation declarations, optional local variable declarations

Invoked by users or applications Stored inside DBMS, part of the schema

Modules communicate via parameters or shared variables


Persistent Stored Modules

Advantages Reduces, in some cases even eliminates, transfer of results to client – Example?

Allows re-use of code (write once – use multiple times)

Encapsulation of database schema shields application programmers from knowing details of how data is stored


Simple PSM Procedure

CREATE PROCEDURE LucasMovies

SELECT title, year

FROM Movie NATURAL JOIN MovieExec

WHERE name = ‘Lucas’;


PSM Procedure with Parameters

CREATE PROCEDURE Move(

IN oldAddr VARCHAR[255],

IN newAddr VARCHAR[255]

)

UPDATE MovieStar

SET address = newAddr

WHERE address = oldAddr;

ParametersMode may be one of IN, OUT, INOUT


A Few Explanations

INOUT parameter combines properties of IN and OUT parameter Pass values into the PSM PSM can set their return values

PSM enforces strict type conformance E.g., parameter of type INT cannot be called with an argument of type VARCHAR


PSM Functions and Procedures

So far, we have seen two examples of PSM procedures Can have IN, OUT, INOUT parameters Optional local variable declarations Executable body of code defining the procedure

PSM function defined in almost same way Use keyword function Specify return type Parameters only of type IN (i.e., no side-effects)

When to use procedure/function? Same reasoning as in programming language applies – which is?


PSM Statements How do we invoke a PSM?

From a host-language program: EXEC SQL CALL Move (:oldA, :newA);

Statement of another PSM As an SQL command issued to SQLPLUS

CALL Move (“LA”, “Boston”); Note, it is not permitted to call a PSM function! You can invoke functions only as part of expressions

Other statements DECLARE <name> <type>; declaration of local variable

SET <variable> = <expression>; assignment statement

IF <cond> THEN <statement list> ELSEIF <cond> THEN <statement list> ELSEIF … ELSE <statement list> END IF;

if-then-elseif-else statement


Miscellaneous

PSM standard has rich syntax Not shown but covered in textbook: Return statements for functions Local variables, assignments, branching, loops

Exception handling Check out Oracle Help topic # 5, “Using Oracle PL/SQL”


SQL Environment

So far, tacitly assumed that our program runs on the same server where the database is installed

Did not worry about explicit connection to database Assumed default connection to the server and the database

In reality, the situation is more complex


SQL Environment

Connection: Want to run program involving SQL at a host where SQL client is running, need to open connection between client and server

SQL-agent(execution of a

module)

SQL Client SQL Server

SQL Environment

Connection

Session(SQL operationsthat are performedwhile connection is active)

Modules Generic SQL

Interface Embedded SQL PSM modules


Call-Level Interfaces A more modern approach to the host-language/SQL connection is a call-level interface (CLI) C (or other language) program creates SQL statements as character strings and passes them to functions that are part of a library

Similar to what really happens in embedded SQL implementations

Two major approaches: SQL/CLI (standard of ODBC = open database connectivity)

JDBC (Java database connectivity), links Java programs to DB in an O-O style


Introduction to JDBC1. Load a driver for the database system we

will use (creates an object called DriverManager)Installation-dependent, see Oracle help pages for details

2. Establish connection to database: applying method getConnection to DriverManager creates variable of type ConnectionJava Statement:Connection myCon = DriverManager.getConnection(<URL>, name,password);


Intuition

By applying the appropriate methods to a connection like myCon, we can create statement objects

Place SQL statements “in” objects Bind values to SQL statement parameters

Execute SQL statements Examine results a tuple at a time


Executing a SELECT Query in JDBC

Query: SELECT netWorth FROM MovieExec;

1. Create statement object and execute directly

Statement execStat=myCon.createStatement();ResultSet Worths=execStat.executeQuery( “SELECT

netWorth FROM MovieExec”);

OR2. Prepare query and execute laterPreparedStatement

execStat=myCon.createStatement(“SELECT netWorth FROM MovieExec”);

ResultSet Worths = execStat.executeQuery();


Executing a Parameter-less Update

Update: Insert new fact into StarsIn table

1. Create statement object and execute directly

Statement starStat=myCon.createStatement();starStat.executeUpdate(“INSERT INTO StarsIn

VALUES (‘Remember the Titans’, 2000, ‘Denzel Washington’)” );

OR

2. Prepare update and execute laterPreparedStatement

starStat=myCon.createStatement(“INSERT INTO StarsIn VALUES (‘Remember the Titans’, 2000, ‘Denzel Washington’)”);

starStat.executeUpdate();


Cursor Operations When we obtain result set object, we may run cursor through tuples of result

ResultSet class provides useful methods Next(), returns FALSE if there is no next tuple

getString(i), getInt(i), getFloat(i), etc. Returns the ith component of the tuple currently indicated by cursor

While(Worths.next()) {Worth = Worths.getInt(1);/* process this net worth */}


Accessing the Result Set

JDBC offers a number of methods to find out where you are in the result set using getRow, isFirst, isBeforeFirst, isLast, isAfterLast

Means to make scroll-able cursors allow free access of any row in the result set

Default, cursors scroll forward only and are read only When creating a Statement for a Connection, you can

change the type of ResultSet to a more flexible scrolling or updatable model:

Statement stmt = MyCon.createStatement( ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

ResultSet rs = stmt.executeQuery("SELECT * FROM MovieExec");


Accessing the Result Set

The different options for types are TYPE_FORWARD_ONLY TYPE_SCROLL_INSENSITIVE TYPE_SCROLL_SENSITIVE

You can choose whether the cursor is read-only or updatable using the options

CONCUR_READ_ONLY CONCUR_UPDATABLE

With default cursor, you can scroll forward using rs.next()

With scroll-able cursors you have more options: rs.absolute(3); // moves to the third tuple rs.previous(); // moves back one tuple (tuple 2) rs.relative(2); // moves forward two tuples (tuple 4) rs.relative(-3); // moves back three tuples (tuple 1)


Parameter Passing How do we pass parameters into query? Use question mark in place of portion of query, then bind values to those parameters

Need to create prepared statement Need to apply to statement objects methods such as

setString(i, v) setInt(i, v)

Bind value v, which must be of appropriate type, to the ith parameter in the query


Parameter Passing

PreparedStatement studioStat=myCon.createStatement(“INSERT INTO Studio(name, address) VALUES (?,?)”);

/* get values for variables studioName and studioAddress from user */

studioStat.setString(1, studioName);

studioStat.setString(2, studioAddr);

studioStat.executeUpdate();


More Info…

For more info on how to use JDBC with CISE’s Oracle installation see:

www.cise.ufl.edu/~jhammer/classes/Oracle/Intro_JDBC.htm

Transactions in SQL


Multi-User Database Access

In many applications, database may need to perform 100’s of ops/sec Initiated at different sites Perhaps involving same part of database at the same time

Operations may interact in strange ways

E.g., banking, airline reservation Let’s look at two specific problems


Example: Order of Operations

void chooseSeat() { /* C code for obtaining flight date and seat, store in three variables */EXEC SQL SELECT occupied INTO :occ

FROM Flights WHERE fltNum = :flight AND fltDate = :date AND

fltSeat = :seat;if (!occ){

EXEC SQL UPDATE FLights SET occupied = TRUE WHERE fltNum = :flight AND fltDate = :date AND

fltSeat = :seat;/* Code to record seat assignments and to inform user of assignment */}

else /* C code to notify user of unavailability andask for another seat selection. */

}


What Could Go Wrong?User 1 finds seat emptytime

User 2 finds seat empty

User 1 sets seatto occupied

User 2 sets seatto occupied

Possible to execute chooseSeat function correctly, yet have global result not be correct

Problem can be solved by SQL mechanism that serves to serialize the execution of the two function executions

Execution of functions is serial if one function executes completely before any other function begins

Execution is serializable if they behave as if they were run serially, even though execution may overlap in time


Example: Execution of Operations as Unity

EXEC SQL BEGIN DECLARE SECTION;int acct1, acct2; /* the two accounts */int balance1; /* amount of money in the first account*/int amount; /* transfer amount

EXEC SQL END DECLARE SECTION;

Example: Transfer Money

Function transfer() that reads two accounts and an amount of money

Checks that the first has at least that much money If so, transfers money from first account to

second


void transfer() { /* C code for obtaining account info and transfer amount */EXEC SQL SELECT balance INTO :balance1

FROM Accounts WHERE acctNo = :acct1;

if (balance1 >= amount){EXEC SQL UPDATE Accounts

SET balance = balance + :amount; WHERE acctNo = :acct2;

EXEC SQL Update Accounts SET balance = balance - :amount; WHERE acctNo = :acct1;

}else /* C code to print message that there were insufficient funds to make transfer. */

}

Cont’d


What Could Go Wrong? If failure occurs between two updates,database

will be left in inconsistent state See that certain operations needs to be done

atomically Either all operations complete or none goes through

Simple solution: make changes in local workspace and commit to database only after all work is done correctly


Solution: Transactions Solution to previous two problems is to group

database operations into transactions Collection of one or more operations on the database

that must be executed atomically In addition, SQL requires that transactions are

executed in serializable manner How to control transactions in embedded SQL or

CLI? Transaction begins as soon as SQL statement begins Optionally: START TRANSACTION Two ways to end transaction:

COMMIT causes transaction to end successfully (exception: deferred constraints)

ROLLBACK causes transaction to abort; any changes made to database are undone (rolled back)

Transactions in generic SQL interface start and end with SQL statement (exception: triggers)


void transfer() { /* C code for obtaining account info and transfer amount */EXEC SQL SELECT balance INTO :balance1

FROM Accounts WHERE acctNo = :acct1;

if (balance1 >= amount){EXEC SQL UPDATE Accounts

SET balance = balance + :amount; WHERE acctNo = :acct2;

EXEC SQL Update Accounts SET balance = balance - :amount; WHERE acctNo = :acct1;

EXEC SQL COMMIT;

}else { /* C code to print message that there were insufficient funds to make transfer. */

EXEC SQL ROLLBACK;}}

Transfer() with Transactions

transactionstarts here


Transaction Properties

Transactions obey the "ACID properties“ Atomicity Consistency Isolation Durability

How are ACID properties achieved? Take COP 4720


Read-Only Transactions

Reading and writing may lead to serialization problems Enforcement of serializability may result in lower transaction throughput

When transaction only reads data, DBMS has more freedom to let transactions execute in parallel EXEC SQL SET TRANSACTION READ ONLY Must be executed before transaction begins


Weaker Properties

There's a lot of overhead to guaranteeing the ACID properties

Sometimes full isolation (i.e., full serializability) is not required

Following is a discussion of some of the ways we can use transactions with less overhead


Dirty Reads Dirty data is a common term for data written by transaction that has not yet committed

Dirty read is read of dirty data Risk in reading dirty data is that transaction that wrote may abort

Dirty data removed from database to roll back to clean state

But: What happens to transaction that has read dirty data and then committed?

Sometimes dirty read matters, sometimes doesn’t Sometimes makes sense to take risk to avoid:

Time-consuming work by DBMS to avoid dirty reads Loss of parallelism that results from waiting until there isno possibility of dirty read


Example 1: New Money Transfer Program P

(1) Add money to account 2(2) Test if account 1 has enough money

If false, remove money from account 2 and abort

If true, subtract money from account 1 and commit

Strange but ok if executed serializably What if dirty reads are possible? Imagine three accounts A1 ($100), A2 ($200),

and A3 ($300) T1 executes P to transfer $150 from A1 to A2

while T2 runs P to transfer $250 from A2 to A3

P


Possible Scenario

T2 adds $250 to A3, now has $550 T1 adds $150 to A2, now has $350 T2 executes test on A2 ($350) and allows transfer from A2 to A3 to occur

T1 executes test of on A1 ($150) which has not enough funds

T2 subtracts $250 from A2 and commits; A2 ($100)

T1 subtracts $150 from A2 which now has -$50; T1 commits


Example 2: New Seat Selection Program S

(1) Find available seat; reserve it by setting occupied flag to 1; if none, abort

(2) Ask customer for approval If yes, commit If no, release seat and set occupied flag to 0;

repeat step 1 to get other seat

Problem: If two transactions execute at roughly the same time, one might reserve seat S, which is later rejected by customer; second transaction may not get option to chose seat for that point in time; may need retry

Dirty read has occurred Not as serious as in previous scenario; re-

running transaction will give seat to second traveler

S


Isolation Level: Allowing Dirty Reads

SET TRANSACTION READ WRITEISOLATION LEVEL READ UNCOMMITTED;

Must specify,ow assumed to be Read-only


Other Isolation Levels

Total of four isolation levels SERIALIZABLE (default) REPEATABLE READ READ COMMITTED READ UNCOMMITTED (Dirty Read)

SET TRANSACTION ISOLATION LEVEL ...

Subtle point: the isolation level of a transaction affects only what data that transaction may see Does not affect what any other transaction sees


Isolation Level: Read Committed

Let’s run seat choosing function with isolation level “read committed”

What happens when other transactions run in parallel?


Isolation Level: Repeatable Read

If tuple is retrieved first time, then we can be sure it is retrieved again if query is repeated

However, new tuples may be visible as well during subsequent executions (phantom tuples)

Example: If we execute seat-choosing problem under repeatable read isolation, if a seat is available on the first query, then it is available under subsequent queries

In addition, if more seats become available (e.g., bigger plane), additional seats also visible during subsequent queries

Date post:	01-Jan-2016
Category:	Documents
Upload:	clara-mitchell
View:	216 times
Download:	0 times

SQL in a Programming Environment - Part II CIS 4301 Lecture Notes Lecture 23 - 13/4/2006.

Documents