Dependency Injection (Inversion of Control in Spring)

Java components/classes should be as independent as possible of other java classes. This increases the possibility to re-use these classes and test them independently of other classes.  To decouple Java components from other Java components, the dependency to a certain/other class should get injected into them rather that the class itself creates / finds this object.  The general concept behind dependency injection is called Inversion of Control.  A class should not configure itself but should be configured from outside.  Spring just adds some simplifications in using dependency injection by providing a standard way of providing the configuration and by managing the reference to the created objects.  The fundamental functionality provided by spring container is dependency injection.  The container allows to inject required objects to other objects.  This results in a loosely coupled design.  Dependency injection in spring is done via setter injection or via constructor injection.

Constructor Versus Setter Injection in Spring

The primary advantage of injection by itself, is that it requires very simple conventions. You don’t have to do anything special in your component and can leave the injector to take over and get stuff done for you.

Dependency Injection via Constructor Arguments:

Constructors with valid arguments gives you a clear statement as of what it means by  creating a valid object at an obvious place. If there are multiple ways to do it, create multiple constructors that gives the different possible combination by which an object needs to be created.  Another advantage with constructor initialization is that it allows to hide any fields which are immutable by simply not providing a setter.  If something should not change, the lack of a setter communicates this very well.

Spring generally advocates the usage of setter-based dependency injection as a large number of constructor arguments can get unwieldy especially when some properties are optional.   Beans defined in the bean factory that uses setter based injection are true java beans.

Basic stuff

A transaction begins with a first statement, and ends up with COMMIT or ROLL BACK.

ACID properties

In Oracle, transactions have ACID properties.

ATOMICITY

Transactions are atomic operations. Individual database statements and stored procedures are treated as atomic statements. They will either succeed or fail in its entirety.

CONSISTENCY

Any transaction takes the database from one logically consistent state to another logically consistent state. In other words the set of business rules is not violated before the transaction started and the time the commit takes place.

ISOLATION

Isolation is the capability of the database to permit concurrent modifications and reads of data within it. The isolation levels are based on three ‘reads’ that are permitted or illegal for each of the isolation levels.

Dirty Read: permits read of uncommitted ‘dirty’ data
Non-repeatable read: a row might change in two consecutive reads
Phantom read: some rows might be added in two consecutive reads (which implies that
more data might satisfy your original query).

Oracle by default won’t allow dirty reads.

Oracle Isolation Levels

Oracle provides these transaction isolation levels.

Isolation Level	Description
Read committed	This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query never reads dirty (uncommitted) data.Because Oracle does not prevent other transactions from modifying the data read by a query, that data can be changed by other transactions between two executions of the query. Thus, a transaction that runs a given query twice can experience both nonrepeatable read and phantoms.
Serializable	Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements. Serializable transactions do not experience nonrepeatable reads or phantoms.
Read-only	Read-only transactions see only those changes that were committed at the time the transaction began and do not allows INSERT, UPDATE, and DELETE statements.

Set the Isolation Level

Application designers, application developers, and database administrators can choose appropriate isolation levels for different transactions, depending on the application and workload. You can set the isolation level of a transaction by using one of these statements at the beginning of a transaction:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED; 

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; 

SET TRANSACTION READ ONLY;

CONCURRENCY CONTROL

Oracle provides lock mechanism to a shared resource. Oracle locks data at the row level, but it uses locks at many different levels to provide concurrent access to various resources.

When we update a row, we do not have to lock it, since Oracle does it for us. There are, however, some situations when explicit locks are necessary. Oracle provides data concurrency and integrity between transactions using its locking mechanisms. Because the locking mechanisms of Oracle are tied closely to transaction control, application designers need only define transactions properly, and Oracle automatically manages locking.

Keep in mind that Oracle locking is fully automatic and requires no user action. Implicit locking occurs for all SQL statements so that database users never need to lock any resource explicitly. Oracle’s default locking mechanisms lock data at the lowest level of restrictiveness to guarantee data integrity while allowing the highest degree of data concurrency.

Modes of Locking

Oracle uses two modes of locking in a multiuser database:

• Exclusive lock mode prevents the associate resource from being shared. This lock mode is obtained to modify data. The first transaction to lock a resource exclusively is the only transaction that can alter the resource until the exclusive lock is released.
• Share lock mode allows the associated resource to be shared, depending on the operations involved. Multiple users reading data can share the data, holding share locks to prevent concurrent access by a writer (who needs an exclusive lock). Several transactions can acquire share locks on the same resource.

Deadlocks

A deadlock can occur when two or more users are waiting for data locked by each other. Deadlocks prevent some transactions from continuing to work. Figure 13-3 is a hypothetical illustration of two transactions in a deadlock. In Figure 13-3, no problem exists at time point A, as each transaction has a row lock on the row it attempts to update. Each transaction proceeds without being terminated. However, each tries next to update the row currently held by the other transaction. Therefore, a deadlock results at time point B, because neither transaction can obtain the resource it needs to proceed or terminate. It is a deadlock because no matter how long each transaction waits, the conflicting locks are held. Figure 13-3 Two Transactions in a Deadlock

Description of “Figure 13-3 Two Transactions in a Deadlock”

Deadlock Detection

Oracle automatically detects deadlock situations and resolves them by rolling back one of the statements involved in the deadlock, thereby releasing one set of the conflicting row locks. A corresponding message also is returned to the transaction that undergoes statement-level rollback.

Multi-versioning and Read Consistency

Oracle implements a multi-version read consistent concurrency model. What that means is that:

1. Queries always produce correct results in a point of time.
2. Queries are never blocked by writers of data.

To illustrate this important concept we follow a transaction example in which potentially long query will get data changed underneath by some other transaction. However, the query returns the snapshot of database at the time the query begin, regardless of the changes in database that happen during the query process. This happens without reader being blocked and without loss of data consistency.

Example

Suppose you have a table called ACCOUNTS, with three columns named ACCOUNT ID, ACCOUNT TYPE, and BALANCE. It can be created at follows:

Create cable accounts
        account-id      number,
        account-type   varchar2(20),
        balance        number
);

Our job is to report the sum of BALANCE accurately and quickly upon demand. We will report the time of day and the total of all account balances. This sounds easy, and the query we need to perform is simply:

select current_timestamp, sum(balance) total_balance from accounts;

Note that CURRENT_TIMESTAMP is a built in column in Oracle 10g that returns the current date and time.

However, the problem is somewhat complicated by the fact that while we are doing this many hundreds or even thousands of transactions will be applied to this database table. People will transfer money from their savings to checking accounts, they’ll be making withdrawals, deposits, and so on. So, as we are running this query the data is changing in the database. We have already seen how we could use READ ONLY or SERIALIZABLE transaction to solve this problem. In this particular case though, we don’t even need to do that, since we have but one SQL query and Oracle processes all statements in a read-consistent fashion. What we are more interested in right now is how this actually takes place.

Let’s say that the ACCOUNTS table looks like this:

Table 3. Example of account in demonstrating read concurrency

ACCOUNTED	ACCOUNT TYPE	BALANCE
1234	Savings	100
5678	Checking	4321
2542	Savings	6232
7653	Savings	234
<hundreds	of thousands	of rows>
1234	Checking	100

Our query will process, row by row, each of the rows in this table when summing up the BALANCE
column. At the same time, the owner of ACCOUNT_ID 1234 is going to transfer $50 from their savings account to their checking account. Lets walk through what happens as these two events take place. In this case our story will have two endings, with one to demonstrate what happens when a query detects locked data, and the other to demonstrate what happens when it detects data that has changed and that it should not see:

Time	Event	Comments
T1	We begin the query in Session 1	It will start reading the table. This will take a couple of minutes, as the ACCOUNTS table is very large. This query has already read the “first row” for the savings account for ACCOUNT_ID 1234 but hasn’t gotten to the checking account row yet.
T2	The owner of account 1234 starts a transaction at an ATM
T3	The owner of account 1234 selects TRANSFER FUNDS and chooses to move $50 from their checking to savings account	The data in the database is updated so the checking account now has $50 and the savings account has $150. The work is net yet committed (but UNDO information is stored).
T4	Our query finally gets to the checking account row for ACCOUNT_ID 1234,	What should happen here? In most every other popular database, the answer would be “The query will wait of course’”. In Oracle it will not.
T5	Detecting that the data is locked by the work performed at T3, our query retrieves the UNDO information (the ‘before’ image of the data) and uses the image of the data that was current as of time T1	Oracle reads around the lock, it does not wait. Our query will read $100 for the checking account.
T6	Our report is done
T7	The ATM commits and completes	x

The interesting part of this is what occurs at time T5 in the above timeline. Oracle reads around the locked data, never stepping the processing of our query (giving us non-blocking reads), and getting the accurate answer as of time T1.

So, having seen what happens when Oracle detects locked data, let’s look at what happens if the data is not locked. We’ll pick up our story at time T4 again:

Time	Event	Comments
T4	The ATM session commits, finishes the transfer	The funds are moved. Other sessions will now have the ability to see $150 in savings and $50 in checking for ACCOUNT_ID 1234
T5	Our query finally gets to the checking account row for ACCOUNT_ID 1234	It is not locked anymore, no one is updating it
T6	Detecting that the data was modified after time T1, our query retrieves the UNDO information and uses the image of the data that was current as of time T1	Our query will again read $1OO for the checking account.
T7	Our report is done

The interesting thing to note here is that even though the data was committed, we did not read it. Instead, we read the data as it existed when our query began. If wee did read it as it was modified then you would report out a balance sum that was $50 less than existed in the bank ever. You would in effect be reporting a number that never existed. No money left the bank, none came to; we just moved some from one row to another. In Oracle you need not worry about that issue. It cannot happen, since the data will always be read consistent.

Oracle readers never block writers, and vice versa. Most of the other RDBMSs require that readers put a share lock
on the data while reading it to provide isolation.

Oracle Flashback Query

Oracle Flashback Query lets you view and repair historical data. You can perform queries on the database as of a certain wall clock time or user-specified system change number (SCN).  Flashback Query uses Oracle’s multiversion read-consistency capabilities to restore data by applying undo as needed. Oracle Database 10g automatically tunes a parameter called the undo retention period. The undo retention period indicates the amount of time that must pass before old undo information—that is, undo information for committed transactions—can be overwritten. The database collects usage statistics and tunes the undo retention period based on these statistics and on undo tablespace size. Using Flashback Query, you can query the database as it existed this morning, yesterday, or last week. The speed of this operation depends only on the amount of data being queried and the number of changes to the data that need to be backed out.

Applications of Flashback Query

• Self-Service Repair

Perhaps you accidentally deleted some important rows from a table and wanted to recover the deleted rows. To      do the repair, you can move backward in time and see the missing rows and re-insert the deleted row into the current   table.

• E-mail or Voice Mail Applications

You might have deleted mail in the past. Using Flashback Query, you can restore the deleted mail by moving back in time and re-inserting the deleted message into the current message box.

• Account Balances

You can view account prior account balances as of a certain day in the month.

• Packaged Applications

Packaged applications (like report generation tools) can make use of Flashback Query without any changes to application logic. Any constraints that the application expects are guaranteed to be satisfied, because users see a consistent version of the Database as of the given time or SCN

Feature	Struts 1	Struts 2
Action classes	Struts 1 requires Action classes to extend an abstract base class. A common problem in Struts 1 is programming to abstract classes instead of interfaces.	An Struts 2 Action may implement an Action interface, along with other interfaces to enable optional and custom services. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit, the Action interface is not required. Any POJO object with a execute signature can be used as an Struts 2 Action object.
Threading Model	Struts 1 Actions are singletons and must be thread-safe since there will only be one instance of a class to handle all requests for that Action. The singleton strategy places restrictions on what can be done with Struts 1 Actions and requires extra care to develop. Action resources must be thread-safe or synchronized.	Struts 2 Action objects are instantiated for each request, so there are no thread-safety issues.
Servlet Dependency	Struts 1 Actions have dependencies on the servlet API since the HttpServletRequest and HttpServletResponse is passed to the execute method when an Action is invoked.	Struts 2 Actions are not coupled to a container. Struts 2 Actions can still access the original request and response, if required.  (This is done by implementing ServletRequestAware and ServletResponseAware interfaces provided by the struts 2 core API).
Testability	A major hurdle to testing Struts 1 Actions is that the execute method exposes the Servlet API.	Struts 2 Actions can be tested by instantiating the Action, setting properties, and invoking methods.
Harvesting Input	Struts 1 uses an ActionForm object to capture input. Like Actions, all ActionForms must extend a base class. Since  other JavaBeans cannot be used as ActionForms, developers often create redundant classes to capture input. DynaActionForm can used as an alternative to creating conventional ActionForm classes, but, here too, developers may be redescribing existing JavaBeans.	Struts 2 uses Action properties as input properties, eliminating the need for a second input object. Input properties may be rich object types which may have their own properties. T
Expression Language	Struts 1 integrates with JSTL, so it uses the JSTL EL. The EL has basic object graph traversal, but relatively weak collection and indexed property support.	Struts 2 can use JSTL, but the framework also supports a more powerful and flexible expression language called “Object Graph Notation Language” (OGNL).
Binding values into views	Struts 1 uses the standard JSP mechanism for binding objects into the page context for access.	Struts 2 uses a “ValueStack” technology so that the taglibs can access values without coupling your view to the object type it is rendering. The ValueStack strategy allows reuse of views across a range of types which may have the same property name but different property types.
Type Conversion	Struts 1 ActionForm properties are usually all Strings. Struts 1 uses Commons-Beanutils for type conversion. Converters are per-class, and not configurable per instance.	Struts 2 uses OGNL for type conversion. The framework includes converters for basic and common object types and primitives.
Validation	Struts 1 supports manual validation via a validate method on the ActionForm, or through an extension to the Commons Validator. Classes can have different validation contexts for the same class, but cannot chain to validations on sub-objects.	Struts 2 supports manual validation via the validate method and the XWork Validation framework. The Xwork Validation Framework supports chaining validation into sub-properties using the validations defined for the properties class type and the validation context.
Control Of Action Execution	Struts 1 supports separate Request Processors (lifecycles) for each module, but all the Actions in the module must share the same lifecycle.	Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks. Custom stacks can be created and used with different Actions, as needed.

Objective of this Session

• Identify high-level architectural components of an Oracle Database
• Describe the function of each of these components
• Identify Oracle Database internal data structures
• Define the mechanisms used when processing Insert/Update/Delete statements

Technically an Oracle Database is broken into two high-level components

1. • INSTANCE – Non-persistent, memory-based processes and structures
   • DATABASE – Persistent, disk-based data and control files

Oracle “Real Application Clusters” allow multiple “Instances” to interact with a single “Database” to provide high availability…

An Oracle Instance…

–        Is a means to access an Oracle Database

–        Always opens one and only one Database

–        Consists of memory and background process structures

Picture of an “Instance”

• System Global Area (SGA): This is a large, shared memory segment that virtually all Oracle processes will access at one point or another.
• Process Global Area (PGA): This is memory that is private to a single process or thread, and is not accessible from other processes/threads.
• User Global Area (UGA): This is memory associated with your session. It will be found either in the SGA or the PGA depending on whether you are connected to the database using shared server (then it will be in the SGA), or dedicated server (it will be in the PGA, in the process memory).

The PGA is a process-specific piece of memory. In other words, it is memory specific to a single operating system process or thread. This memory is not accessible by any other process/thread in the system. It is typically allocated via either of the C runtime calls malloc() or memmap(), and it may grow (and shrink even) at runtime. The PGA is never allocated in Oracle’s SGA—it is always allocated locally by the process or thread.

The UGA is, in effect, your session’s state. It is memory that your session must always be able to get to. The location of the UGA is wholly dependent on how you connected to Oracle.

Oracle’s memory structure consists of two memory areas known as:

1. System Global Area (SGA): Allocated at instance start up, and is a fundamental component of an Oracle Instance
2. Program Global Area (PGA): Allocated when the server process is started

The SGA consists of several memory structures:

1. • Shared Pool
   • Database Buffer Cache
   • Redo Log Buffer
   • Other structures
2. There are two additional memory structures that can be configured within the SGA:
   1. Large Pool (Starting in Oracle8, a DBA can configure an optional, specialized memory region called the large pool, that holds items for shared server operations, backup and restore tasks, and other miscellaneous things.  The large_pool_size parameter controls this memory region.  The large pool is also used for sorting when the multi-threaded server (MTS) is implemented.    Multi-Threaded-Server.
      Oracle definition: MTS allows many user processes to share very few server processes. Without MTS, each user process requires its own dedicated server process; a new server process is created for each client requesting a connection. A dedicated server process remains associated to the user process for the remainder of the connection. With MTS many user processes connect to a dispatcher process. The dispatcher routes client requests to the next available shared server process. The advantage of MTS is that system overhead is reduced, so the number of users that can be supported is increased.)
   2. Java Pool(This area handles the memory for Java methods, class definitions, etc.  The java_pool_size parameter controls the amount of memory for this area.  Useful for SQL-J to be run on the embedded JServer(A standard for embedding SQL in java programs))

The SGA_MAX_SIZE parameter sets the maximum size of the SGA (so you can limit it) and is not a dynamic parameter

Shared Pool

• Used to store:

–        Most recently executed SQL statements

–        Most recently used data definitions

• It consists of two key performance-related memory structures:

–        Library Cache

–        Data Dictionary Cache

• Sized by the parameter SHARED_POOL_SIZE

Library Cache

• Stores information about the most recently used SQL and PL/SQL statements
• Enables the sharing of commonly used statements
• Is managed by a least recently used (LRU) algorithm
• Consists of two structures

–        Shared SQL area

–        Shared PL/SQL area

Data Dictionary Cache

• A collection of the most recently used definitions in the database
• Includes information about database files, tables, indexes, columns, users, privileges, and other database objects
• During the parse phase, the server process looks at the data dictionary for information to resolve object names and validate access

Database Buffer Cache

• Stores copies of data blocks that have been retrieved from the data files
• Enables great performance gains when you obtain and update data
• Managed through an LRU algorithm

Redo Log Buffer

• Records all changes made to the database data blocks/ data files
• Primary purpose is recovery
• Changes recorded within are called redo entries
• Redo entries contain information to reconstruct or redo changes

Oracle Database Picture

ORACLE “PROCESS” STRUCTURE

• Oracle takes advantage of various types of Processes:

–        User Process: Started at the time a database user requests connection to the Oracle Server

–        Server Process: Connects to the Oracle instance and is started when a user establishes a session

–        Background Processes: Started when an Oracle instance is started

User Process

• A program that requests interaction with the Oracle server
• Must first establish a connection
• Does not interact directly with the Oracle server

Server Process

• A program that directly interacts with the Oracle server
• Fulfills calls generated and returns results
• Can be dedicated or shared server (A dedicated server process, which services only one user process, A shared server process, which can service multiple user processes)

Background Processes

• Maintains and enforces relationships between physical and memory structures

–        Mandatory background processes:

DBWR(Database Writer)         PMON            (Process Monitor) CKPT(CheckPoint)

LGWR (Logwriter) SMON(System Monitor)

–        Optional background processes:

ARCn              LMDn              QMNn

CJQ0               LMON              RECO

Dnnn                LMS                Snnn

LCKn              Pnnn

Slave processes: These are similar to background processes, but they are processes that perform extra work on behalf of either a background or a server process.

DBWn (The database block writer (DBWn) is the background process responsible for writing dirty blocks to disk. DBWn will write dirty blocks from the buffer cache, usually to make more room in the cache (to free buffers for reads of other data) .  As you can see, the performance of DBWn can be crucial. If it does not write out blocks fast enough to free buffers (buffers that can be reused to cache some other blocks) for us, we will see both the number and duration of waits on Free Buffer Waits and Write Complete Waits start to grow. It writes when: (Database Block Writer)

• Checkpoint occurs
• Dirty buffers reach threshold
• There are no free buffers

LGWR writes:

The LGWR process is responsible for flushing to disk the contents of the redo log buffer located in the SGA. It does this when one of the following is true:

• At commit
• When there is 1 MB of redo or if the redo log buffer is one third full.
• Every three seconds
• Before DBWR writes

System Monitor (SMON)

Responsibilities:

• Instance recovery

–        Rolls forward changes in online redo log files

–        Opens database for user access

–        Rolls back uncommitted transactions

• Coalesces/combines free space
• Deallocates temporary segments

Process Monitor (PMON)

This process is responsible for cleaning up after abnormally terminated connections. For example, if your dedicated server “fails” or is killed for some reason, PMON is the process responsible for fixing (recovering or undoing work) and releasing your resources. PMON will initiate the rollback of uncommitted work, release locks, and free SGA resources allocated to the failed process.

In addition to cleaning up after aborted connections, PMON is responsible for monitoring the other Oracle background processes and restarting them if necessary (and if possible). If a shared server or a dispatcher fails (crashes), PMON will step in and restart another one (after cleaning up for the failed process).

Cleans up after failed processes by:

• Rolling back the transaction
• Releasing locks
• Releasing other resources
• Restarting dead dispatchers

Checkpoint (CKPT)

Responsible for:

• Signaling DBWR at checkpoints(A checkpoint is when the   DBWR writes all modified buffers in the SGA to the database files.)
• Updating datafile headers with checkpoint information
• Updating control files with checkpoint information

• Connection: A connection is a physical path from a client to an Oracle instance. A connection is established either over a network or over an IPC mechanism. A connection is typically between a client process and either a dedicated server or a dispatcher. However, using Oracle’s Connection Manager (CMAN), a connection may be between a client and CMAN, and CMAN and the database. Coverage of CMAN is beyond the scope of this discussion, but Oracle Net Services Administrator’s Guide (freely available from http://otn.oracle.com) covers it in some detail.
• Session: A session is a logical entity that exists in the instance. It is your session state, or a collection of data structures in memory that represents your unique session. It is what would come first to most people’s minds when thinking of a “database connection.” It is your session in the server, where you execute SQL, commit transactions, and run stored procedures.

SQL Statements (IUDS) Workflow Analysis

• Insert
• Update
• Delete
• Select

What happens when someone connects to the database and issues one of these statements?

Connect to Oracle – What Happens

• Are “User” definition and privileges in SGA “Dictionary Cache”?

–        If not, try to fetch from the “System” tablespace

–        If there, validate Pwd and privileges to login

–        Allow connection if all is right; otherwise decline connection

“Select” – What Happens First?

Sample SQL Query

Select *

From MyTab

Order by 1;

• Is this statement in the “Library Cache”?

–        If statement cached then it has been recently been “parsed” and “executed”

–        If not cached then “parse” the statement

–        If cached then skip parsing stage and execute statement

“Select” – Parsing the Statement

• Does “MyTab” exist?
• Does user have Privs to select from “MyTab”
• What columns are in “MyTab”
• What is the first column in “MyTab”

“Select” – Executing the Statement

• Is “MyTab” data in the SGA “Buffer Cache”?

–        If not, fetch data into Buffer Cache

• Sort data in “MyTab” by the first column

–        If can sort records in memory then do so

–        If cannot sort in memory then use “Temporary” tablespace as disk-based staging area

• Return records to client process

Insert (a,b,c)

Into MyTab;

“I/U/D” – What Happens First?

• Is this statement in the “Library Cache”?

–        If statement cached then it has been recently been “parsed” and “executed”

–        If not cached then “parse” the statement

–        If cached then skip parsing stage and execute statement

“I/U/D” – Executing the Statement

• Validate values to be inserted
• Execute the statement

–        Keep DB version of the record in “Undo” tablespace until Commit or Rollback

–        Record changes in SGA “Redo Log Buffer”

–        Change records in SGA “Buffer Cache”

–        DBWR writes changed records to data file(s) as part of buffer cache management

• If “Commit” then…

–        LGWR writes “Redo Log Buffer” entries to “Redo Logs”

–        Undo entries are invalidated

• If “Rollback” then…

–        Migrate DB version of record in Undo back to tablespace/data file

—————————————————————————————————————————————————

Thank you!