text:
|Oracle® Database Application Developer's Guide - Fundamentals
10g Release 1 (10.1)
Part Number B10795-01
|View PDF
This chapter describes how Oracle Database processes Structured Query Language (SQL) statements. Topics include the following:
Figure 5-1 outlines the stages commonly used to process and execute a SQL statement. In some cases, these steps might be executed in a slightly different order. For example, the
DEFINE stage could occur just before the
FETCH stage, depending on how your code is written.
For many Oracle tools, several of the stages are performed automatically. Most users do not need to be concerned with, or aware of, this level of detail. However, you might find this information useful when writing Oracle Database applications.
|See Also:
Oracle Database Concepts for a description of the processing stages for each type of SQL statement
The Federal Information Processing Standard for SQL (FIPS 127-2) requires a way to identify SQL statements that use vendor-supplied extensions. Oracle Database provides a FIPS flagger to help you write portable applications.
When FIPS flagging is active, your SQL statements are checked to see whether they include extensions that go beyond the ANSI/ISO SQL92 standard. If any non-standard constructs are found, then Oracle Database flags them as errors and displays the violating syntax.
The FIPS flagging feature supports flagging through interactive SQL statements submitted using Oracle Enterprise Manager or SQL*Plus. The Oracle precompilers and SQL*Module also support FIPS flagging of embedded and module language SQL.
When flagging is on and non-standard SQL is encountered, the following message is returned:
ORA-00097: Use of Oracle SQL feature not in SQL92 level Level
Where level can be either
INTERMEDIATE, or
Text description of the illustration adfns052.gif
In general, only application designers using the programming interfaces to Oracle Database are concerned with which types of actions should be grouped together as one transaction. Transactions must be defined properly so that work is accomplished in logical units and data is kept consistent. A transaction should consist of all of the necessary parts for one logical unit of work, no more and no less. Data in all referenced tables should be in a consistent state before the transaction begins and after it ends. Transactions should consist of only the SQL statements or PL/SQL blocks that comprise one consistent change to the data.
A transfer of funds between two accounts (the transaction or logical unit of work), for example, should include the debit to one account (one SQL statement) and the credit to another account (one SQL statement). Both actions should either fail or succeed together as a unit of work; the credit should not be committed without the debit. Other non-related actions, such as a new deposit to one account, should not be included in the transfer of funds transaction.
In addition to determining which types of actions form a transaction, when you design an application, you must also determine if you can take any additional measures to improve performance. You should consider the following performance enhancements when designing and writing your application. Unless otherwise noted, each of these features is described in Oracle Database Concepts.
TRANSACTION command with the
SEGMENT parameter to explicitly assign a transaction to an appropriate rollback segment. This can eliminate the need to dynamically allocate additional extents, which can reduce overall system performance.
TRANSACTION command with the
LEVEL set to
SERIALIZABLE to get ANSI/ISO serializable transactions.
ANALYZE command to collect statistics that can be used by Oracle Database to implement a cost-based approach to SQL statement optimization. You can supply additional "hints" to the optimizer as needed.
SET_ACTION procedure before beginning a transaction to register and name a transaction for later use when measuring performance across an application. You should specify what type of activity a transaction performs so that the system tuners can later see which transactions are taking up the most system resources.
MAX_OPEN_CURSORS can often reduce the frequency of parsing and improve performance.
|See Also:
To commit a transaction, use the
COMMIT command. The following two statements are equivalent and commit the current transaction:
COMMIT command lets you include the
COMMENT parameter along with a comment (less than 50 characters) that provides information about the transaction being committed. This option is useful for including information about the origin of the transaction when you commit distributed transactions:
COMMIT COMMENT 'Dallas/Accts_pay/Trans_type 10B';
To roll back an entire transaction, or to roll back part of a transaction to a savepoint, use the
ROLLBACK command. For example, either of the following statements rolls back the entire current transaction:
WORK option of the
ROLLBACK command has no function.
To roll back to a savepoint defined in the current transaction, use the
TO option of the
ROLLBACK command. For example, either of the following statements rolls back the current transaction to the savepoint named
SAVEPOINT Point1; ... ROLLBACK TO SAVEPOINT Point1; ROLLBACK TO Point1;
To define a savepoint in a transaction, use the
SAVEPOINT command. The following statement creates the savepoint named
ADD_EMP1 in the current transaction:
SAVEPOINT Add_emp1;
If you create a second savepoint with the same identifier as an earlier savepoint, the earlier savepoint is erased. After creating a savepoint, you can roll back to the savepoint.
There is no limit on the number of active savepoints for each session. An active savepoint is one that has been specified since the last commit or rollback.
Table 5-3 shows a series of SQL statements that illustrates the use of
SAVEPOINT, and
ROLLBACK statements within a transaction.
|SQL Statement
First savepoint of this transaction
First DML statement of this transaction
Second savepoint of this transaction
Second DML statement of this transaction
Third savepoint of this transaction
Third DML statement of this transaction.
New DML statement in this transaction
Commits all actions performed by the first DML statement (the
All other statements (the second and the third statements) of the transaction were rolled back before the
No privileges are required to control your own transactions; any user can issue a
ROLLBACK, or
SAVEPOINT statement within a transaction.
By default, the consistency model for Oracle Database guarantees statement-level read consistency, but does not guarantee transaction-level read consistency (repeatable reads). If you want transaction-level read consistency, and if your transaction does not require updates, then you can specify a read-only transaction. After indicating that your transaction is read-only, you can execute as many queries as you like against any database table, knowing that the results of each query in the read-only transaction are consistent with respect to a single point in time.
A read-only transaction does not acquire any additional data locks to provide transaction-level read consistency. The multi-version consistency model used for statement-level read consistency is used to provide transaction-level read consistency; all queries return information with respect to the system change number (SCN) determined when the read-only transaction begins. Because no data locks are acquired, other transactions can query and update data being queried concurrently by a read-only transaction.
Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions. Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. Your database administrator can specify a retention period by using the parameter
|See Also:
Oracle Database Administrator's Guide for information on long-running queries and resumable space allocation
For example, if
UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the OER error, "snapshot too old."
A read-only transaction is started with a
TRANSACTION statement that includes the
ONLY option. For example:
TRANSACTION statement must be the first statement of a new transaction; if any DML statements (including queries) or other non-DDL statements (such as
SET ROLE) precede a
ONLY statement, an error is returned. Once a
ONLY statement successfully executes, only
SELECT (without a
UPDATE clause),
ROLLBACK, or non-DML statements (such as
TABLE) are allowed in the transaction. Otherwise, an error is returned. A
ROLLBACK, or DDL statement terminates the read-only transaction; a DDL statement causes an implicit commit of the read-only transaction and commits in its own transaction.
PL/SQL implicitly declares a cursor for all SQL data manipulation statements, including queries that return only one row. For queries that return more than one row, you can explicitly declare a cursor to process the rows individually.
A cursor is a handle to a specific private SQL area. In other words, a cursor can be thought of as a name for a specific private SQL area. A PL/SQL cursor variable enables the retrieval of multiple rows from a stored procedure. Cursor variables allow you to pass cursors as parameters in your 3GL application. Cursor variables are described in PL/SQL User's Guide and Reference.
Although most Oracle Database users rely on the automatic cursor handling of the database utilities, the programmatic interfaces offer application designers more control over cursors. In application development, a cursor is a named resource available to a program, which can be specifically used for parsing SQL statements embedded within the application.
There is no absolute limit to the total number of cursors one session can have open at one time, subject to two constraints:
OPEN_CURSORS found in the parameter file (such as
|See Also:
Oracle Database Reference for descriptions of parameters
Explicitly creating cursors for precompiler programs can offer some advantages in tuning those applications. For example, increasing the number of cursors can often reduce the frequency of parsing and improve performance. If you know how many cursors may be required at a given time, then you can make sure you can open that many simultaneously.
After each stage of execution, the cursor retains enough information about the SQL statement to reexecute the statement without starting over, as long as no other SQL statement has been associated with that cursor. This is illustrated in Figure 5-1. Notice that the statement can be reexecuted without including the parse stage.
By opening several cursors, the parsed representation of several SQL statements can be saved. Repeated execution of the same SQL statements can thus begin at the describe, define, bind, or execute step, saving the repeated cost of opening cursors and parsing.
To understand the performance characteristics of a cursor, a DBA can retrieve the text of the query represented by the cursor using the
V$SQL catalog view. Because the results of
EXPLAIN PLAN on the original query might differ from the way the query is actually processed, a DBA can get more precise information by examining the
V$SQL_PLAN_STATISTICS, and
V$SQL_PLAN_STATISTICS_ALL catalog views.:
V$SQL_PLAN view contains the execution plan information for each child cursor loaded in the library cache.
V$SQL_PLAN_STATISTICS view provides execution statistics at the row source level for each child cursor.
V$SQL_PLAN_STATISTICS_ALL view contains memory usage statistics for row sources that use SQL memory (sort or hash-join). This view concatenates information in
V$SQL_PLAN with execution statistics from
V$SQL_PLAN_STATISTICS and
|See Also:
Oracle Database Reference for details on these views
Closing a cursor means that the information currently in the associated private area is lost and its memory is deallocated. Once a cursor is opened, it is not closed until one of the following events occurs:
Cancelling a cursor frees resources from the current fetch.The information currently in the associated private area is lost but the cursor remains open, parsed, and associated with its bind variables.
|See Also:
Oracle Call Interface Programmer's Guide for more information about cancelling cursors
Oracle Database always performs necessary locking to ensure data concurrency, integrity, and statement-level read consistency. You can override these default locking mechanisms. For example, you might want to override the default locking of Oracle Database if:
The automatic locking mechanisms can be overridden at the transaction level. Transactions including the following SQL commands override Oracle Database's default locking:
SELECT, including the
UPDATE clause
TRANSACTION with the
ONLY or
SERIALIZABLE options
Locks acquired by these statements are released after the transaction is committed or rolled back.
The following sections describe each option available for overriding the default locking of Oracle Database. The initialization parameter
DML_LOCKS determines the maximum number of DML locks allowed.
|See Also:
Oracle Database Reference for a discussion of parameters
Although the default value is usually enough, you might need to increase it if you use additional manual locks.
If you override the default locking of Oracle Database at any level, be sure that the overriding locking procedures operate correctly: Ensure that data integrity is guaranteed, data concurrency is acceptable, and deadlocks are not possible or are appropriately handled.
A transaction explicitly acquires the specified table locks when a
TABLE statement is executed. A
TABLE statement manually overrides default locking. When a
TABLE statement is issued on a view, the underlying base tables are locked. The following statement acquires exclusive table locks for the
EMP_TAB and
DEPT_TAB tables on behalf of the containing transaction:
LOCK TABLE Emp_tab, Dept_tab IN EXCLUSIVE MODE NOWAIT;
You can specify several tables or views to lock in the same mode; however, only a single lock mode can be specified for each
TABLE statement.
You can also indicate if you do or do not want to wait to acquire the lock. If you specify the
NOWAIT option, then you only acquire the table lock if it is immediately available. Otherwise an error is returned to notify that the lock is not available at this time. In this case, you can attempt to lock the resource at a later time. If
NOWAIT is omitted, then the transaction does not proceed until the requested table lock is acquired. If the wait for a table lock is excessive, then you might want to cancel the lock operation and retry at a later time; you can code this logic into your applications.
LOCK TABLE Emp_tab IN ROW SHARE MODE; LOCK TABLE Emp_tab IN ROW EXCLUSIVE MODE;
ROW SHARE and
ROW EXCLUSIVE table locks offer the highest degree of concurrency. You might use these locks if:
LOCK TABLE Emp_tab IN SHARE MODE;
SHARE table locks are rather restrictive data locks. You might use these locks if:
SHARE locks on the table either commit or roll back.
SHARE table locks on the same table, also allowing them the option of transaction-level read consistency.
Your transaction may or may not update the table later in the same transaction. However, if multiple transactions concurrently hold share table locks for the same table, no transaction can update the table (even if row locks are held as the result of a
For example, assume that two tables,
EMP_TAB and
BUDGET_TAB, require a consistent set of data in a third table,
DEPT_TAB. For a given department number, you want to update the information in both of these tables, and ensure that no new members are added to the department between these two transactions.
Although this scenario is quite rare, it can be accommodated by locking the
DEPT_TAB table in
MODE, as shown in the following example. Because the
DEPT_TAB table is rarely updated, locking it probably does not cause many other transactions to wait long.
You may need to set up data structures similar to the following for certain examples to work:
CREATE TABLE dept_tab( deptno NUMBER(2) NOT NULL, dname VARCHAR2(14), loc VARCHAR2(13)); CREATE TABLE emp_tab ( empno NUMBER(4) NOT NULL, ename VARCHAR2(10), job VARCHAR2(9), mgr NUMBER(4), hiredate DATE, sal NUMBER(7,2), comm NUMBER(7,2), deptno NUMBER(2)); CREATE TABLE Budget_tab ( totsal NUMBER(7,2), deptno NUMBER(2) NOT NULL);
LOCK TABLE Dept_tab IN SHARE MODE; UPDATE Emp_tab SET sal = sal * 1.1 WHERE deptno IN (SELECT deptno FROM Dept_tab WHERE loc = 'DALLAS'); UPDATE Budget_tab SET Totsal = Totsal * 1.1 WHERE Deptno IN (SELECT Deptno FROM Dept_tab WHERE Loc = 'DALLAS'); COMMIT; /* This releases the lock */
LOCK TABLE Emp_tab IN SHARE ROW EXCLUSIVE MODE;
You might use a
SHARE ROW EXCLUSIVE table lock if:
UPDATE), which might make
UPDATE and
INSERT statements in the locking transaction wait and might cause deadlocks.
LOCK TABLE Emp_tab IN EXCLUSIVE MODE;
You might use an
EXCLUSIVE table if:
You can automatically acquire any type of table lock on tables in your schema. To acquire a table lock on a table in another schema, you must have the
TABLE system privilege or any object privilege (for example,
SELECT or
UPDATE) for the table.
Letting Oracle Database control table locking means your application needs less programming logic, but also has less control, than if you manage the table locks yourself.
Issuing the command
TRANSACTION ISOLATION LEVEL SERIALIZABLE or
SESSION ISOLATION LEVEL SERIALIZABLE preserves ANSI serializability without changing the underlying locking protocol. This technique allows concurrent access to the table while providing ANSI serializability. Getting table locks greatly reduces concurrency.
|See Also:
The settings for these parameters should be changed only when an instance is shut down. If multiple instances are accessing a single database, then all instances should use the same setting for these parameters.
You can override default locking with a
SELECT statement that includes the
UPDATE clause. This statement acquires exclusive row locks for selected rows (as an
UPDATE statement does), in anticipation of updating the selected rows in a subsequent statement.
You can use a
UPDATE statement to lock a row without actually changing it. For example, several triggers in Chapter 9, "Using Triggers", show how to implement referential integrity. In the
EMP_DEPT_CHECK trigger (see "Foreign Key Trigger for Child Table"), the row that contains the referenced parent key value is locked to guarantee that it remains for the duration of the transaction; if the parent key is updated or deleted, referential integrity would be violated.
UPDATE statements are often used by interactive programs that allow a user to modify fields of one or more specific rows (which might take some time); row locks are acquired so that only a single interactive program user is updating the rows at any given time.
If a
UPDATE statement is used when defining a cursor, the rows in the return set are locked when the cursor is opened (before the first fetch) rather than being locked as they are fetched from the cursor. Locks are only released when the transaction that opened the cursor is committed or rolled back, not when the cursor is closed.
Each row in the return set of a
UPDATE statement is locked individually; the
UPDATE statement waits until the other transaction releases the conflicting row lock. If a
UPDATE statement locks many rows in a table, and if the table experiences a lot of update activity, it might be faster to acquire an
EXCLUSIVE table lock instead.
The return set for a
This can cause a deadlock between sessions querying the table concurrently with DML operations when rows are locked in a non-sequential order. To prevent such deadlocks, design your application so that any concurrent DML on the table does not affect the return set of the query. If this is not feasible, you may want to serialize queries in your application.
When acquiring row locks with
UPDATE, you can specify the
NOWAIT option to indicate that you are not willing to wait to acquire the lock. If you cannot acquire then lock immediately, an error is returned to signal that the lock is not possible at this time. You can try to lock the row again later.
By default, the transaction waits until the requested row lock is acquired. If the wait for a row lock is too long, you can code logic into your application to cancel the lock operation and try again later.
You can use Oracle Lock Management services for your applications by making calls to the
DBMS_LOCK package. It is possible to request a lock of a specific mode, give it a unique name recognizable in another procedure in the same or another instance, change the lock mode, and release it. Because a reserved user lock is the same as an Oracle Database lock, it has all the features of a database lock, such as deadlock detection. Be certain that any user locks used in distributed transactions are released upon
COMMIT, or an undetected deadlock can occur.
|See Also:
PL/SQL Packages and Types Reference for detailed information on the
User locks can help to:
The following Pro*COBOL precompiler example shows how locks can be used to ensure that there are no conflicts when multiple people need to access a single device.
***************************************************************** * Print Check * * Any cashier may issue a refund to a customer returning goods. * * Refunds under $50 are given in cash, more than $50 by check. * * This code prints the check. The one printer is opened by all * * the cashiers to avoid the overhead of opening and closing it * * for every check. This means that lines of output from multiple* * cashiers could become interleaved if we don't ensure exclusive* * access to the printer. The DBMS_LOCK package is used to * * ensure exclusive access. * ***************************************************************** CHECK-PRINT * Get the lock "handle" for the printer lock. MOVE "CHECKPRINT" TO LOCKNAME-ARR. MOVE 10 TO LOCKNAME-LEN. EXEC SQL EXECUTE BEGIN DBMS_LOCK.ALLOCATE_UNIQUE ( :LOCKNAME, :LOCKHANDLE ); END; END-EXEC. * Lock the printer in exclusive mode (default mode). EXEC SQL EXECUTE BEGIN DBMS_LOCK.REQUEST ( :LOCKHANDLE ); END; END-EXEC. * We now have exclusive use of the printer, print the check. ... * Unlock the printer so other people can use it EXEC SQL EXECUTE BEGIN DBMS_LOCK.RELEASE ( :LOCKHANDLE ); END; END-EXEC.
Table 5-4 describes Oracle Database facilities to display locking information for ongoing transactions within an instance.
Oracle Enterprise Manager 10g Database Control
From the Additional Monitoring Links section of the Database Performance page, click Database Locks to display user blocks, blocking locks, or the complete list of all database locks. Refer to Oracle Database 2 Day DBA for more information.
By default, Oracle Database permits concurrently executing transactions to modify, add, or delete rows in the same table, and in the same data block. Changes made by one transaction are not seen by another concurrent transaction until the transaction that made the changes commits.
If a transaction A attempts to update or delete a row that has been locked by another transaction B (by way of a DML or
UPDATE statement), then A's DML command blocks until B commits or rolls back. Once B commits, transaction A can see changes that B has made to the database.
For most applications, this concurrency model is the appropriate one, because it provides higher concurrency and thus better performance. But some rare cases require transactions to be serializable. Serializable transactions must execute in such a way that they appear to be executing one at a time (serially), rather than concurrently. Concurrent transactions executing in serialized mode can only make database changes that they could have made if the transactions ran one after the other.
Figure 5-2 shows a serializable transaction (B) interacting with another transaction (A).
The ANSI/ISO SQL standard SQL92 defines three possible kinds of transaction interaction, and four levels of isolation that provide increasing protection against these interactions. These interactions and isolation levels are summarized in Table 5-3.
|Isolation Level
|Dirty ReadFoot 1
|Non-Repeatable ReadFoot 2
|Phantom ReadFoot 3
Not possible
Not possible
Not possible
Not possible
Not possible
Not possible
|1 A transaction can read uncommitted data changed by another transaction.
2 A transaction rereads data committed by another transaction and sees the new data.
3 A transaction can execute a query again, and discover new rows inserted by another committed transaction.
The behavior of Oracle Database with respect to these isolation levels is summarized in Table 5-4.
|Isolation Level
Oracle Database never permits "dirty reads." Although some other database products use this undesirable technique to improve thoughput, it is not required for high throughput with Oracle Database.
Oracle Database meets the
Oracle Database does not normally support this isolation level, except as provided by
Oracle Database does not normally support this isolation level, except as provided by
Figure 5-2 shows how a serializable transaction (Transaction B) interacts with another transaction (A, which can be either
SERIALIZABLE or
When a serializable transaction fails with an
ORA-08177 error ("cannot serialize access"), the application can take any of several actions:
Oracle Database stores control information in each data block to manage access by concurrent transactions. To use the
SERIALIZABLE isolation level, you must use the
INITRANS clause of the
TABLE or
TABLE command to set aside storage for this control information. To use serializable mode,
INITRANS must be set to at least 3.
Text description of the illustration adfns053.gif
You can change the isolation level of a transaction using the
LEVEL clause of the
TRANSACTION command, which must be the first command issued in a transaction.
Use the
SESSION command to set the transaction isolation level on a session-wide basis.
|See Also:
Oracle Database Reference for the complete syntax of the
Oracle Database stores control information in each data block to manage access by concurrent transactions. Therefore, if you set the transaction isolation level to
SERIALIZABLE, then you must use the
TABLE command to set
INITRANS to at least 3. This parameter causes Oracle Database to allocate sufficient storage in each block to record the history of recent transactions that accessed the block. Higher values should be used for tables that will undergo many transactions updating the same blocks.
Because Oracle Database does not use read locks, even in
SERIALIZABLE transactions, data read by one transaction can be overwritten by another. Transactions that perform database consistency checks at the application level should not assume that the data they read will not change during the execution of the transaction (even though such changes are not visible to the transaction). Database inconsistencies can result unless such application-level consistency checks are coded carefully, even when using
SERIALIZABLE transactions. Note, however, that the examples shown in this section are applicable for both
COMMITTED and
SERIALIZABLE transactions.
Figure 5-3 shows two different transactions that perform application-level checks to maintain the referential integrity parent/child relationship between two tables. One transaction checks that a row with a specific primary key value exists in the parent table before inserting corresponding child rows. The other transaction checks to see that no corresponding detail rows exist before deleting a parent row. In this case, both transactions assume (but do not ensure) that data they read will not change before the transaction completes.
Text description of the illustration adfns054.gif
The read issued by transaction A does not prevent transaction B from deleting the parent row, and transaction B's query for child rows does not prevent transaction A from inserting child rows. This scenario leaves a child row in the database with no corresponding parent row. This result occurs even if both A and B are
SERIALIZABLE transactions, because neither transaction prevents the other from making changes in the data it reads to check consistency.
As this example shows, sometimes you must take steps to ensure that the data read by one transaction is not concurrently written by another. This requires a greater degree of transaction isolation than defined by SQL92
SERIALIZABLE mode.
Fortunately, it is straightforward in Oracle Database to prevent the anomaly described:
UPDATE to query and lock the parent row and thereby prevent transaction B from deleting the row.
Referential integrity can also be enforced in Oracle Database using database triggers, instead of a separate query as in Transaction A. For example, an
INSERT into the child table can fire a
BEFORE INSERT row-level trigger to check for the corresponding parent row. The trigger queries the parent table using
UPDATE, ensuring that parent row (if it exists) remains in the database for the duration of the transaction inserting the child row. If the corresponding parent row does not exist, the trigger rejects the insert of the child row.
SQL statements issued by a database trigger execute in the context of the SQL statement that caused the trigger to fire. All SQL statements executed within a trigger see the database in the same state as the triggering statement. Thus, in a
COMMITTED transaction, the SQL statements in a trigger see the database as of the beginning of the triggering statement execution, and in a transaction executing in
SERIALIZABLE mode, the SQL statements see the database as of the beginning of the transaction. In either case, the use of
UPDATE by the trigger correctly enforces referential integrity.
Oracle Database gives you a choice of two transaction isolation levels with different characteristics. Both the
COMMITTED and
SERIALIZABLE isolation levels provide a high degree of consistency and concurrency. Both levels reduce contention, and are designed for deploying real-world applications. The rest of this section compares the two isolation modes and provides information helpful in choosing between them.
A useful way to describe the
COMMITTED and
SERIALIZABLE isolation levels in Oracle Database is to consider:
An operation (a query or a transaction) is transaction set consistent if its read operations all return data written by the same set of committed transactions. When an operation is not transaction set consistent, some reads reflect the changes of one set of transactions, and other reads reflect changes made by other transactions. Such an operation sees the database in a state that reflects no single set of committed transactions.
Oracle Database transactions executing in
COMMITTED mode are transaction-set consistent on an individual-statement basis, because all rows read by a query must be committed before the query begins.
Oracle Database transactions executing in
SERIALIZABLE mode are transaction set consistent on an individual-transaction basis, because all statements in a
SERIALIZABLE transaction execute on an image of the database as of the beginning of the transaction.
In other database systems, a single query run in
READ COMMITTED mode provides results that are not transaction set consistent. The query is not transaction set consistent, because it may see only a subset of the changes made by another transaction. For example, a join of a master table with a detail table could see a master record inserted by another transaction, but not the corresponding details inserted by that transaction, or vice versa. Oracle Database's
COMMITTED mode avoids this problem, and so provides a greater degree of consistency than read-locking systems.
In read-locking systems, at the cost of preventing concurrent updates, SQL92
READ isolation provides transaction set consistency at the statement level, but not at the transaction level. The absence of phantom protection means two queries issued by the same transaction can see data committed by different sets of other transactions. Only the throughput-limiting and deadlock-susceptible
SERIALIZABLE mode in these systems provides transaction set consistency at the transaction level.
Table 5-5 summarizes key similarities and differences between
COMMITTED and
SERIALIZABLE transactions.
|Read Committed
Dirty write
Not Possible
Not Possible
Dirty read
Not Possible
Not Possible
Non-repeatable read
Not Possible
Not Possible
Compliant with ANSI/ISO SQL 92
Read snapshot time
Transaction set consistency
Statement level
Transaction level
Row-level locking
Readers block writers
Writers block readers
Different-row writers block writers
Same-row writers block writers
Waits for blocking transaction
Subject to "can't serialize access" error
Error after blocking transaction aborts
Error after blocking transaction commits
Choose an isolation level that is appropriate to the specific application and workload. You might choose different isolation levels for different transactions. The choice depends on performance and consistency needs, and consideration of application coding requirements.
For environments with many concurrent users rapidly submitting transactions, you must assess transaction performance against the expected transaction arrival rate and response time demands, and choose an isolation level that provides the required degree of consistency while performing well. Frequently, for high performance environments, you must trade-off between consistency and concurrency (transaction throughput).
Both Oracle Database isolation modes provide high levels of consistency and concurrency (and performance) through the combination of row-level locking and Oracle Database's multi-version concurrency control system. Because readers and writers do not block one another in Oracle Database, while queries still see consistent data, both
READ COMMITTED and
SERIALIZABLE isolation provide a high level of concurrency for high performance, without the need for reading uncommitted ("dirty") data.
COMMITTED isolation can provide considerably more concurrency with a somewhat increased risk of inconsistent results (due to phantoms and non-repeatable reads) for some transactions. The
SERIALIZABLE isolation level provides somewhat more consistency by protecting against phantoms and non-repeatable reads, and may be important where a read/write transaction executes a query more than once. However,
SERIALIZABLE mode requires applications to check for the "can't serialize access" error, and can significantly reduce throughput in an environment with many concurrent transactions accessing the same data for update. Application logic that checks database consistency must take into account the fact that reads do not block writes in either mode.
When a transaction runs in serializable mode, any attempt to change data that was changed by another transaction since the beginning of the serializable transaction causes an error:
ORA-08177: Can't serialize access for this transaction.
When you get this error, roll back the current transaction and execute it again. The transaction gets a new transaction snapshot, and the operation is likely to succeed.
To minimize the performance overhead of rolling back transactions and executing them again, try to put DML statements that might conflict with other concurrent transactions near the beginning of your transaction.
This section gives a brief overview of autonomous transactions and what you can do with them.
|See Also:
PL/SQL User's Guide and Reference and Chapter 9, "Using Triggers" for detailed information on autonomous transactions
At times, you may want to commit or roll back some changes to a table independently of a primary transaction's final outcome. For example, in a stock purchase transaction, you may want to commit a customer's information regardless of whether the overall stock purchase actually goes through. Or, while running that same transaction, you may want to log error messages to a debug table even if the overall transaction rolls back. Autonomous transactions allow you to do such tasks.
An autonomous transaction (AT) is an independent transaction started by another transaction, the main transaction (MT). It lets you suspend the main transaction, do SQL operations, commit or roll back those operations, then resume the main transaction.
An autonomous transaction executes within an autonomous scope. An autonomous scope is a routine you mark with the pragma (compiler directive)
AUTONOMOUS_TRANSACTION. The pragma instructs the PL/SQL compiler to mark a routine as
autonomous (independent). In this context, the term routine includes:
Figure 5-4 shows how control flows from the main routine (MT) to an autonomous routine (AT) and back again. As you can see, the autonomous routine can commit more than one transaction (AT1 and AT2) before control returns to the main routine.
Text description of the illustration adfns055.gif
When you enter the executable section of an autonomous routine, the main routine suspends. When you exit the routine, the main routine resumes.
COMMIT and
ROLLBACK end the active autonomous transaction but do not exit the autonomous routine. As Figure 5-4 shows, when one transaction ends, the next SQL statement begins another transaction.
A few more characteristics of autonomous transactions:
Figure 5-5 illustrates some of the possible sequences autonomous transactions can follow.
Text description of the illustration adfns056.gif
The two examples in this section illustrate some of the ways you can use autonomous transactions.
As these examples illustrate, there are four possible outcomes that can occur when you use autonomous and main transactions. Table 5-6 presents these possible outcomes. As you can see, there is no dependency between the outcome of an autonomous transaction and that of a main transaction.
|Autonomous Transaction
|Main Transaction
Rolls back
Rolls back
Rolls back
Rolls back
In this example, illustrated by Figure 5-6, a customer enters a buy order. That customer's information (such as name, address, phone) is committed to a customer information table--even though the sale does not go through.
Text description of the illustration adfns057.gif
In this example, a customer tries to make a withdrawal from a bank account. In the process, a main transaction calls one of two autonomous transaction scopes (AT Scope 1, and AT Scope 2).
The following diagrams illustrate three possible scenarios for this transaction.
There are sufficient funds to cover the withdrawal and therefore the bank releases the funds. This is illustrated by Figure 5-7.
Text description of the illustration adfns058.gif
There are insufficient funds to cover the withdrawal, but the customer has overdraft protection. The bank therefore releases the funds. This is illustrated by Figure 5-8.
Text description of the illustration adfns059.gif
There are insufficient funds to cover the withdrawal, the customer does not have overdraft protection, and the bank therefore withholds the requested funds. This is illustrated by Figure 5-9.
Text description of the illustration adfns060.gif
Note: This section is provided here to round out your general understanding of autonomous transactions. For a more thorough understanding of autonomous transactions, see PL/SQL User's Guide and Reference.
To define autonomous transactions, you use the pragma (compiler directive)
AUTONOMOUS_TRANSACTION. The pragma instructs the PL/SQL compiler to mark the procedure, function, or PL/SQL block as autonomous (independent).
You can code the pragma anywhere in the declarative section of a procedure, function, or PL/SQL block. But, for readability, code the pragma at the top of the section. The syntax follows:
In the following example, you mark a packaged function as autonomous:
CREATE OR REPLACE PACKAGE Banking AS FUNCTION Balance (Acct_id INTEGER) RETURN REAL; -- add additional functions and packages END Banking; CREATE OR REPLACE PACKAGE BODY Banking AS FUNCTION Balance (Acct_id INTEGER) RETURN REAL IS PRAGMA AUTONOMOUS_TRANSACTION; My_bal REAL; BEGIN --add appropriate code END; -- add additional functions and packages... END Banking;
Note the following restrictions on autonomous transactions.
CREATE OR REPLACE PACKAGE Banking AS PRAGMA AUTONOMOUS_TRANSACTION; -- illegal FUNCTION Balance (Acct_id INTEGER) RETURN REAL; END Banking;
PIPE ROW statement in your autonomous routine while your autonomous transaction is open. You must close the autonomous transaction before executing the
PIPE ROW statement. This is normally accomplished by committing or rolling back the autonomous transaction before executing the
PIPE ROW statement.
|See Also:
When a long-running transaction is interrupted by an out-of-space error condition, your application can suspend the statement that encountered the problem and resume it after the space problem is corrected. This capability is known as resumable storage allocation. It lets you avoid time-consuming rollbacks, without the need to split the operation into smaller pieces and write your own code to track its progress.
Queries, DML operations, and certain DDL operations can all be resumed if they encounter an out-of-space error. The capability applies if the operation is performed directly by a SQL statement, or if it is performed within a stored procedure, anonymous PL/SQL block, SQL*Loader, or an OCI call such as
Operations can be resumed after these kinds of error conditions:
Certain storage errors cannot be handled using this technique. In dictionary-managed tablespaces, you cannot resume an operation if you run into the limit for rollback segments, or the maximum number of extents while creating an index or a table. Use locally managed tablespaces and automatic undo management in combination with this feature.
When an operation is suspended, your application does not receive the usual error code. Instead, perform any logging or notification by coding a trigger to detect the
AFTER SUSPEND event and call the functions in the
DBMS_RESUMABLE package to get information about the problem. Using this package, you can:
DBMS_RESUMABLE.SPACE_ERROR_INFO function. For details about this function, see PL/SQL Packages and Types Reference.
SET_TIMEOUT procedure.
Within the body of the trigger, you can perform any notifications, such as sending a mail message to alert an operator to the space problem.
Alternatively, the DBA can periodically check for suspended statements using the data dictionary views
USER_RESUMABLE, and
When the space condition is corrected (usually by the DBA), the suspended statement automatically resumes execution. If it is not corrected before the timeout period expires, the operation causes a
SERVERERROR exception.
To reduce the chance of out-of-space errors within the trigger itself, you must declare it as an autonomous transaction so that it uses a rollback segment in the
SYSTEM tablespace. If the trigger encounters a deadlock condition because of locks held by the suspended statement, the trigger is aborted and your application receives the original error condition, as if it was never suspended. If the trigger encounters an out-of-space condition, the trigger and the suspended statement are rolled back. You can prevent the rollback through an exception handler in the trigger, and just wait for the statement to be resumed.
|See Also:
Oracle Database Reference for details on the
This trigger handles applicable storage errors within the database. For some kinds of errors, it aborts the statement and alerts the DBA that this has happened through a mail message. For other errors that might be temporary, it specifies that the statement should wait for eight hours before resuming, with the expectation that the storage problem will be fixed by then.
CREATE OR REPLACE TRIGGER suspend_example AFTER SUSPEND ON DATABASE DECLARE cur_sid NUMBER; cur_inst NUMBER; err_type VARCHAR2(64); object_owner VARCHAR2(64); object_type VARCHAR2(64); table_space_name VARCHAR2(64); object_name VARCHAR2(64); sub_object_name VARCHAR2(64); msg_body VARCHAR2(64); ret_value boolean; error_txt varchar2(64); mail_conn utl_smtp.connection; BEGIN SELECT DISTINCT(sid) INTO cur_sid FROM v$mystat; cur_inst := userenv('instance'); ret_value := dbms_resumable.space_error_info(err_type, object_owner, object_ type, table_space_name, object_name, sub_object_name); IF object_type = 'ROLLBACK SEGMENT' THEN INSERT INTO sys.rbs_error ( SELECT sql_text, error_msg, suspend_time FROM dba_ resumable WHERE session_id = cur_sid AND instance_id = cur_inst); SELECT error_msg into error_txt FROM dba_resumable WHERE session_id = cur_sid AND instance_id = cur_inst; msg_body := 'Subject: Space error occurred: Space limit reached for rollback segment '|| object_name || ' on ' || to_char(SYSDATE, 'Month dd, YYYY, HH:MIam') || '. Error message was: ' || error_txt; mail_conn := utl_smtp.open_connection('localhost', 25); utl_smtp.helo(mail_conn, 'localhost'); utl_smtp.mail(mail_conn, 'sender@localhost'); utl_smtp.rcpt(mail_conn, 'recipient@localhost'); utl_smtp.data(mail_conn, msg_body); utl_smtp.quit(mail_conn); dbms_resumable.abort(cur_sid); ELSE dbms_resumable.set_timeout(3600*8); END IF; COMMIT; END;


text:
No. 96,365
1. K.S.A. 2005 Supp. 22-3716(a) contemplates that probation revocation proceedings commence during the period of probation. Subject only to K.S.A. 2005 Supp. 22-3716(d), the court's jurisdiction generally ceases with the termination of the probationary period.
2. In the absence of approval by the court and timely filing under K.S.A. 2005 Supp. 21-4611(c)(8), an agreement to extend probation cannot create jurisdiction for revocation beyond the initial term of probation. A probationer cannot by agreement create jurisdiction for the court to act beyond the maximum period set forth in the statutes.
3. Notwithstanding general jurisdictional restrictions, probation may be extended by the court under K.S.A. 2005 Supp. 21-4611(c)(8), pursuant to a modification hearing and a judicial finding of necessity.
4. The substantive jurisdiction of the court, its power to adjudicate, cannot be created by waiver or consent; on the other hand, want of jurisdiction of the person or thing may be waived.
5. By its clear language, the 30-day "grace period" under K.S.A. 2005 Supp. 22-3716(d) does not apply to extension agreements. There is no statutory authority that allows the court to take revocation action for an alleged probation violation occurring during the period of a probation extension by voluntary agreement where the agreement has not been approved by the court pursuant to K.S.A. 2005 Supp. 21-4611(c)(8) and filed prior to expiration of the initial probation period.
Appeal from Lyon District Court; MERLIN G. WHEELER, judge. Opinion filed December 8, 2006. Reversed and remanded with directions.
B. Joyce Yeager, of Yeager Law Firm, LLC, of Overland Park, for appellant.
Vernon E. Buck, first assistant county attorney, Marc Goodman, county attorney, and Phill Kline, attorney general, for appellee.
Before GREENE, P.J., CAPLINGER, J., and LARSON, S.J.
GREENE: Angelo R. Cisneros appeals the district court's revocation of his probation, arguing that the alleged violation of a condition of probation occurred after his probation had expired, thus depriving the court of jurisdiction for any revocation. We agree, reverse the district court, and order Cisneros discharged.
Cisneros pled no contest to one count of attempted possession of paraphernalia and two counts of conspiracy to possess methamphetamine with intent to sell, deliver, or distribute within 1,000 feet of school property. He was granted probation for 12 months with an underlying prison term of 24 months, and one of the conditions of probation was to follow recommendations imposed as a result of drug evaluation. By the last day of his probation period, Cisneros had not yet completed recommended substance abuse counseling. He agreed to extend his probation, but the voluntary probation extension agreement was not approved and filed until 4 days after the expiration of his probation.
One month later, Cisneros admitted to testing positive for alcohol in a urinalysis test and admitted to drinking two pitchers of beer at a bar, thus violating a condition of his probation. On November 7, 2005, the State moved to revoke Cisneros' probation, and at a hearing thereafter, the district court revoked Cisneros' probation and ordered him to serve his prison term. Cisneros appeals.
Whether the district court has jurisdiction to revoke probation is a question of law over which this court's review is unlimited. State v. Williams, 20 Kan. App. 2d 142, 145, 884 P.2d 743 (1994). Interpretation of a sentencing statute is a question of law, and the appellate court's standard of review is also unlimited. State v. Walker, 280 Kan. 513, 515, 124 P.3d 39 (2005).
"'The general rule is that a criminal statute must be strictly construed in favor of the accused, which simply means that words are given their ordinary meaning. Any reasonable doubt about the meaning is decided in favor of anyone subjected to the criminal statute. This rule of strict construction, however, is subordinate to the rule that judicial interpretation must be reasonable and sensible to effect legislative design and intent.' [Citation omitted.]" State v. McCurry, 279 Kan. 118, 121, 105 P.3d 1247 (2005).
"When a statute is plain and unambiguous, the court must give effect to the intention of the legislature as expressed, rather than determine what the law should or should not be." State v. Gordon, 275 Kan. 393, 397, 66 P.3d 903 (2003).
While Cisneros argues that his probation officer did not have authority to extend his probation, he does not directly raise the effect of the delayed approval and filing of the extension agreement on the district court's jurisdiction to revoke his probation. An appellate court has a duty to question jurisdiction, however, whether it be for the first time on appeal or upon the court's own motion. Mid-Continent Specialists, Inc. v. Capital Homes, 279 Kan. 178, 185, 106 P.3d 483 (2005).
Our statute governing the revocation of probation clearly contemplates that revocation proceedings commence during the period of probation. K.S.A. 2005 Supp. 22-3716(a) provides in material part:
"At any time during probation, assignment to a community correctional services program, suspension of sentence or pursuant to subsection (d) for defendants who committed a crime prior to July 1, 1993, and at any time during which a defendant is serving a nonprison sanction for a crime committed on or after July 1, 1993, or pursuant to subsection (d), the court may issue a warrant for the arrest of a defendant for violation of any of the conditions of release or assignment. . . ." (Emphasis added.)
We have consistently construed this statute to be jurisdictional, holding that the court maintains continuing jurisdiction over a probationer during the time he or she is on probation. See, e.g., State v. Farmer, 16 Kan. App. 2d 419, 422, 824 P.2d 998 (1992). Subject only to K.S.A. 2005 Supp. 22-3716(d), the court's jurisdiction ceases with the termination of the probationary period. State v. Williams, 20 Kan. App. 2d 142, 146-47, 884 P.2d 743 (1994); Farmer, 16 Kan. App. 2d at 422.
Notwithstanding these general jurisdictional restrictions, however, probation may be extended by the court under K.S.A. 2005 Supp. 21-4611(c)(8), which provides:
"The court may modify or extend the offender's period of supervision, pursuant to a modification hearing and a judicial finding of necessity. Such extensions may be made for a maximum period of five years or the maximum period of the prison sentence that could be imposed, whichever is longer, inclusive of the original supervision term."
The question presented by this appeal is whether a district court may modify and extend probation pursuant to K.S.A. 2005 Supp. 21-4611(c)(8) after the initial period of probation has expired, where the probationer voluntarily and timely agreed to such an extension.
In addressing the validity of a voluntary agreement of a probationer to extend the term of his or her probation under similar circumstances, this court has held that such an agreement cannot create jurisdiction beyond the initial term of probation, reasoning as follows:
"[The defendant] could not agree to an illegal sentence. He could not by agreement create jurisdiction for the court to act beyond the period set forth in the statutes. His agreement to extend his probationary term beyond the maximum period allowed by law is a nullity. To say as the State does in this case that the court had jurisdiction to act because the defendant voluntarily submitted himself to the court's jurisdiction confuses subject matter jurisdiction with in personam jurisdiction. The substantive jurisdiction of the court, its power to adjudicate, cannot be created by waiver or consent; on the other hand, want of jurisdiction of the person or thing may be waived." State v. Grimsley, 15 Kan. App. 2d 441, 445, 808 P.2d 1387 (1991).
Here, Cisneros signed his extension agreement within the term of his probation, but the agreement was neither approved by the court nor filed until after his probation had expired. The State argues, however, that the approval and filing of the extension agreement during the statutory 30-day "grace period" following expiration renders the agreement of legal validity. In so arguing, the State relies on K.S.A. 2005 Supp. 22-3716(d), which provides:
"The court shall have 30 days following the date probation, assignment to a community correctional service program, suspension of sentence or a nonprison sanction was to end to issue a warrant for the arrest or notice to appear for the defendant to answer a charge of a violation of the conditions of probation, assignment to a community correctional service program, suspension of sentence of a nonprison sanction."
By its clear language, this statute does not apply to extension agreements. The statute allows the court to issue a warrant or notice to appear and answer allegations of probation violations (which presumably have occurred during the period of probation), but it does not generally provide a 30-day "grace period" to address any other issues that may arise or affect the initial period of probation. Moreover, we note that K.S.A. 2005 Supp. 21-4611(c)(8), addressing modification or extension of probation, does not specify any such "grace period" for the finalization of an extension agreement. There is simply no statutory authority that allows the court to take revocation action for an alleged probation violation occurring during the period of a probation extension by voluntary agreement where the agreement has not been timely approved by the court pursuant to K.S.A. 2005 Supp. 21-4611(c)(8) and filed prior to expiration of the initial probation period.
This conclusion is consistent with our decision in State v. Powers, 29 Kan. App. 2d 166, 25 P.3d 147 (2001). In Powers, a case involving the timeliness of the filing of a voluntary agreement to extend probation, the defendant signed the voluntary agreement to extend probation 2 days before her probation was to expire, but the order was not filed with the district court until 2 days after her probation expired. The court upheld the agreement only because the defendant's probation was set to expire on a Saturday and under K.S.A. 60-206(a), expiration was not effective until the end of the next business day. The key date determining jurisdiction in Powers was the date that the agreement was filed with the court, not the date that the defendant signed the voluntary extension agreement. 29 Kan. App. 2d at 166-68. Implicit in Powers is that an agreement to extend probation must be approved and filed prior to expiration of the initial period and must otherwise comply with K.S.A. 2005 Supp. 21-4611(c)(8).
The district court lost jurisdiction to modify or extend Cisneros' probation when Cisneros' probation terminated on Thursday, August 25, 2005. When the voluntary extension order was filed with the district court on Monday, August 29, 2005, the district court's jurisdiction over Cisneros had already terminated. Thus, the district court did not have jurisdiction to modify or extend Cisneros' probation, and when the State initiated revocation proceedings in November, the district court no longer had jurisdiction to revoke Cisneros' probation. The district court's revocation of Cisneros' probation must be reversed for lack of jurisdiction. Cisneros is entitled to be discharged.
Reversed and remanded with directions to discharge the defendant.

subset: commoncrawl


text:
SPARTANBURG, S.C. --- Jenah Tracy (Naples, Fla.) and Olivia Gudewich (Frederick, Md.) each scored to pace the Lees-McRae College women's lacrosse team on Monday evening, as Converse College outscored the Bobcats by a 6-2 margin in the second half en route to a 15-2 victory in Conference Carolinas play.
Converse (8-6, 2-2 CC) outshot Lees-McRae (3-7, 0-5 CC) by a 27-6 margin in the contest, including an 11-5 advantage in the second half, while converting 8-of-9 clears and recording 22 ground balls. The Bobcats converted 7-of-10 clearing attempts and scooped up 11 grounders on the night.
Tracy and Gudewich each found the back of the net for the Bobcats, as Gudewich tallied her 72nd career goal to move within two strikes of moving into a tie for second on the program's all-time list. Gudewich and Taylor Drake (Jupiter, Fla.) both scooped up a pair of ground balls, while Mia Emmerson (Orlando, Fla.) made eight saves between the pipes.
Brianna Hoffman led the way for Converse with five goals, as Chelsea Worrell added three strikes and one assist. Jordy Taylor and Sam Green each chipped in two goals, while Brooke Bondurant posted a game-high three assists. Alexandra Gurecki, Sandra Ponce, and Erin Mathers combined for two saves in the contest.
Converse jumped out to an early 4-0 lead in the first half, when Worrell scored at the 10:05 mark before she and Murphy each added a strike, pushing the margin to 6-0 with 8:29 left in the period. The Valkyries would add three more in the first half, taking a 9-0 lead into the intermission, before opening the second period with a 3-0 run.
Gudewich got the Bobcats on the board at the 17:19 mark of the second half, before Tracy added a strike for Lees-McRae with 8:28 to play.
Lees-McRae returns to action on Wednesday when the Bobcats host No. 3 Limestone College in conference play at 6 p.m. on Tate Field. The Bobcats will honor their senior class with a special pre-game ceremony.


text:
This event ends in 382 days
Virtual Career Event April 1 - 30, 2017
- Choose the category you're looking for
- View the employers & positions
- Your profile is sent to ALL or just the employers you select.
- Get Started Below!
Opportunities are waiting for YOU!
Highlight your skills to employers now.
Welcome to the Digital First Media - MediaOneNE Virtual Career Event.
Explore available opportunities by viewing participating companies.
Answer a few questions to send a skill profile with your resume. Employers match your skill profile to their hiring needs.
Click categories to get started and add your skill profile.


text:
Grind Mode Cypher "Worldstarhiphop" Freestyle Pt. 2 [Unsigned Hype]
The second installment in the special series of the Grind Mode Cypher for WorldStarHipHop. The Grind Mode Cypher has been spreading across the northeast for the past year, featuring the best emcees from New England. Check out the newest release in the hottest cypher series.
This cypher features Lingo, McCoy Price, A Money Gramz, Sbo, V.I., Gread & J-Hook$.
Produced by Lingo
Directed by SevOneMedia.com
Please click the "Report" button below if the video on this page is not working properly.
Comments will only be displayed by verified emails. No Spamming or Racism.


text:
Historical Context
Table ofContents
This lesson is based on the National Register of Historic Places registration files, "Herbert Hoover National Historic Site" (with photographs) and "West Branch Commercial Historic District," and materials from Herbert Hoover National Historic Site. It was written by Pat Wheeler, former Chief of Resource Education and Public Use Management at Herbert Hoover National Historic Site. TwHP is sponsored, in part, by the Cultural Resources Training Initiative and Parks as Classrooms programs of the National Park Service. This lesson is one in a series that brings the important stories of historic places into the classrooms across the country.
Where it fits into the curriculum
Topics: This lesson could be used in connection with studies of World War I, as an introduction to Hoover's presidency and the Great Depression, or in a unit devoted to citizenship.
Time period: 1870s-1930s
Relevant United States History Standards for Grades 5-12
Relevant Curriculum Standards for Social Studies
Find your state's social studies and history standards for grades Pre-K-12
Objectives for students
1) To relate the events of Herbert Hoover's childhood in West Branch, Iowa, that may have motivated his concern for children around the world.
2) To understand the daily life of a rural community in the 1870s and 1880s.
3) To describe and evaluate the activities that led to Hoover's recognition as a good citizen of the world.
4) To discuss and give examples of ways they can act as good citizens in their own community.
Materials for studentsThe materials listed below either can be used directly on the computer or can be printed out, photocopied, and distributed to students. The photos, drawing, posters, and cartoons appear twice: in a low-resolution version with associated questions and alone in a larger, high-resolution version.
1) a map of Iowa;
2) readings compiled from contemporary writings and quotations;
3) a copy of Cedar County Clerk Records;
4) images of Hoover's birthplace;
5) posters from World War I;
6) political cartoons.
Visiting the site
Herbert Hoover National Historic Site, administered by the National Park Service, is open from 9 a.m. to 5 p.m. daily, except January 1, Thanksgiving, and December 25. For more information, write to the Superintendent, Herbert Hoover National Historic Site, P.O. Box 607, West Branch, IA 52358 or visit the park web pages.


text:
Hong Kong Exchange Program
Study at Lingnan University
Students study at the only Liberal Arts University in China
- Fall, spring or academic year. (Note: Chinese nationals are not permitted to study in Hong Kong in their final semester of studies.)
- Curriculum:
- Courses taught in English
- Study Hong Kong and Asia in the Cultural Studies and other programs as well as courses with a service-learning focus.
- Humanities and social science courses including philosophy, history, business and comparative literature
- Most courses equal .75 Beloit course units, so students enroll in 5 courses
- Basic Cantonese available
- Housing in double rooms with local roommates in campus hostels. Purchase meals in campus dining facilities (canteen and restaurant) and nearby restaurants or cook in hostel kitchens.
- Costs: Beloit College tuition and room, the Beloit activities fee, $50 overseas administrative fee, and a $90 wellness fee.
- Eligibility:
- Students are strongly encouraged to enroll in courses in anthropology, Asian studies, economics, art history, political science, history or philosophy with an Asian focus as preparation for this program. Mandarin Chinese may be useful but is not required.
- Program highlights: Study liberal arts in an economic center of Asia and learn Hong Kong perspectives on your fields of study. Excellent library and sports facilities, opportunities for service learning, university provided excursions, student clubs and activities, Asian travel opportunities.
History of the Hong Kong Exchange Program
Photos: Housing estates near Lingnan University (upper right), Lingnan University canteen (center right), neighborhood residents practice Tai Chi on Lingnan University's main plaza (top)
Credit Translation Table:
|US Semester Hours
|Beloit Units


text:
will.i.am and Prince Andrew team up for technology initiative
will.i.am is teaming up with PRINCE ANDREW to equip youngsters with cutting edge technology skills.
The Duke of York is behind the Inspiring Digital Enterprise Award (IDEA) initiative which seeks to provide young people with expertise in areas such as coding, computing and marketing to help them launch their own business.
The Black Eyed Peas hitmaker forged a partnership with the prince following a meeting at Buckingham Palace where the two struck up a conversation about the need to provide opportunities for city teenagers.
The rapper tells TV show Good Morning Britain, "I got invited to Buckingham Palace where Prince Andrew was there and I was so over the moon and full of excitement and I was telling him, 'Young kids in the cities, we need to find opportunities for them'... I didn't think that conversation would follow up with 'Hey let's partner up'!"
The Duke of York adds, "I thought, 'Well, here's somebody who has the similar viewpoint as me, who knows more about the digital world than I do'... If we don't give young people the skills to be able to work in this environment they are going to feel more ostracised than they may or may not be today."
The project will provide 20 teams of youngsters with the chance to pitch their ideas for a digital business to a panel of experts, with three finalist teams being handed £15,000 to launch a start-up company.


text:
Offenses reported
Theft and criminal deprivation of property
A 2003 Buick LeSabre and a cell phone were stolen from the 200 block of N. D St., Ramona, at about 10 p.m. Jan. 3. The vehicle was recovered on Jan. 4 with damage inflicted. The car is valued at $5,100; the cell phone is valued at $25.
Three Newton-based hunters were the victims of theft at about midnight on Dec. 26 in the 1200 block K-15, Goessel. A deer stand, trail cam, and self-climbing deer stand top section were stolen; the items are valued at $200.
Last modified Jan. 10, 2013
© 2019 HOCH PUBLISHING | Marion County Record | Hillsboro Star-Journal | Peabody Gazette-Bulletin | Checkerboard


text:
Dal-Dhokli means cooked Indian flat-bread bites, submerged in spicy and tangy lentil soup. Dal-Dhokli is ultimate comfort food in Gujarati household. My Dal-Dhokli recipe is inspired by the famous Gujarati chef Tarla Dalal. Each time it comes out perfect. It is great for soggy rainy weather.
Approx 4 servings
Prep Time: 10 mins
Cooking Time: 20 mins
For Dhokli:
- Whole wheat flour – 1.5 cups
- Besan (Bengal gram flour) – 1/2 cup
- Ajwain (Carom seeds) – 2 tsp
- Red chili powder – 1 tsp
- Asafetida – 1 pinch
- Salt as per taste
- Cooking oil – 2 tbsp
For Dal:
- Tuwar dal (yellow lentils) – 1 cup uncooked
- Tomatoes – 1/2 cup
- Boiled peanuts – 2 tbsp
- Ginger – 1 tbsp finely chopped
- Green chilies – 2 finely chopped
- Curry leaves – 8
- Jaggery (gur)- 1 tbsp
- Tamarind pulp (Imli) – 1 tbsp
- Red chili powder – 1 tsp
- Turmeric powder – 1 tsp
- Garam masala – 1 tsp
- Salt as per taste
For tempering:
- Cooking oil – 2 tbsp
- Cumin seeds – 2 tsp
- Asafetida (Hing) -1/4 tsp
- Finely chopped cilantro – 2 tbsp (for garnish)
For Dhokli:
- Combine all the ingredients in a bowl, mix well and knead into soft dough, using enough water.
- Cover and keep aside for 15-20 minutes.
- Divide the dough into equal portions and roll out each portion into 6″ diameter and 1/8 inch thick circles.
- Heat griddle or tava and cook each roti lightly from both the sides.
- Cut each roti with pizza cutter or knife into diamond or desired shapes and keep aside.
For Dal:
- Cook dal in the pressure cooker with turmeric powder and salt. Keep aside.
- Heat the oil in large sauce pan and add cumin seeds. When seeds start crackling, add finely chopped green chilies and ginger. Sauté for a minute.
- Now add asafetida powder, red chili powder and the cooked dal. Mix well and bring it to a boil.
- Add the curry leaves, tomatoes, jaggery, tamarind pulp and peanuts. Simmer for 10-15 minutes.
Garnish and Serving Suggestions:
Garnish hot dal with freshly chopped cilantro. For plating, just before serving add prepared dhoklis to hot dal and serve immediately.
Note: Add dhoklis one by one to the dal or it will form a lump.


text:
Festivals for the Culture
17th of May is Norwegian Constitution Day, which is celebrated in Seattle's Ballard neighborhood with a variety of events, culminating with a parade down Market St. at 6 p.m.
Seatac International Festival June 25 10 a.m.-8 p.m., June 26 10 a.m.-5 p.m., Angle Lake Park, Sea Tac. 206-973-4680; www.ci.seatac.wa.us.
July 9-10. Chinatown-International District Dragon Fest. Hing Hay Park bustles for a weekend with what is touted as the largest Pan-Asian festival in the Pacific Northwest. Formerly known as the Summer Festival, Dragon Fest runs from noon to 8 p.m. on July 9 and from noon to 5 p.m. on July 10. 206-382-1197; www.cidbia.org.
July 16-17: Seafair Indian Days Pow Wow. Follow the smell of baked salmon to the Daybreak Star Center in Discovery Park, where Indian traditional singers, dancers, drummers and artists will converge for a two day party. 206-285-4425 ext. 1035; www.unitedindians.com.
July 18-19. Seattle Bon Odori Seattle Buddhist Temple hosts this free Japanese festival. 206-329-0800. www.seattlebetsuin.com.
July 31: Hispanic Seafair Festival.
August 1. Pista Sa Nayon. Touted as the largest Filipino-American outdoor event in the country, this harvest festival celebration takes place in Seward Park. 206-612-4406.
August 5-7: Umoja Fest African heritage festival takes place in Judkins Park, and includes a parade on August 6. 877-505-6306.
Sept. 16-18: The St. Demetrios Greek Festival has a weekend of food, music and Greek dancing at St. Demetrios Greek Orthodox Church. This year marks the 50th annual Greek festival at St. Demetrios. 2100 Boyer Ave. E. 206-325-4347.