Controller and Concurrency

Model View Controller

Because programs and scripts are good at processing the request and server pages are good at formatting responses, there is a natural pattern that arises called the Model View Controller.

A controller selects the model to use, carries out the domain logic and chooses the view to use, the view acquires the relevant data to display from the model.

MVC Advantages

ensures that the models are completely separated from the web presentation

easier to modify the presentation

    easier to add additional presentation layers

easier to test domain logic

Page Controller

When controlling logic is simple, a page controller pattern can be used. There is one page controller foreach logical page of the application, or more strictly for each action such as a button or link.

The page controller manipulates the model appropriately and selects the next view.

Front Controller

When controlling logic becomes more complicated, a front controller pattern can be adopted. There is one front controller for the entire application.

 The front controller selects the appropriate model to use based on which view was active and proceeds more or less as a page controller.

Each of the commands shares a fair bit of data and behavior and will need to be initialized with information from the Web server. They can also provide common behavior such as a forward method.

Application Controller

Sometimes the presentation objects are separated from the domain objects using an intermediate layer of application controller objects, which is like wizard style application:

   handles the flow of the application, deciding which screen should appear in which order depending on the current state and the command received.

  maybe considered part of the presentation layer or a separate layer between presentation and domain

   maybe independent of any particular presentations

        can be reused between presentations

If the screen order is controlled by the user then there is little use for anapplication controller.

View Patterns

Two main patterns:

Template View: write the presentation in the structure of the page and embed markers into the page to indicate

                         where dynamic content is needed.

Transform View: uses a transform style language like XSLT, which works well if your data is in or can easily be

                           converted to XML.

For each of the main patterns we can apply a either a single step view or two step view.

Single Step View: One view component for each screen in the application.

Two Step View: 

The first stage creates a logical screen, the second stage renders the logical screen. There is one first stage for each screen and one second stage across all screens.

Uses of Two Step View

Works better if you have a Web application where its services are being used by multiple front-end customers, such as multiple air-lines fronting the same basic reservation system.

Different second stages can be used for different output devices.E.g. for regular web browsers and for palmtops.

Each customer can have their own customized appearance

    isolates appearance logic

Concurrency

Concurrency problems occur whenever there is multiple processes or threads manipulating the same data.

Concurrency correctness is hard to test for because there is a large number of possible scenarios.

The transaction manager in the database helps to avoid concurrency problems at the level of a single database transaction. However not all interactions in a system can be placed within a single database transaction.

Offline concurrency refers to concurrency that can not be handled by a single database transaction.

Concurrency Problems

Essential problems:

    Lost updates occur when a record is updated by process A while the same record is currently being edited by process B; the update by process B overwrites the update of process A.

    Inconsistent reads can occur when several reads by process A happen currently with another process B that is writing to the same data.

    Subsequent requests may come before current requests have finished.

Isolation and immutability

Two important general solutions:

    Isolation is about partitioning the data so that any piece of it is only accessible by a single active agent.

    Immutable data removes concurrency concerns because reading data that will not change does not introduce problems.

    However, sometimes data is mutable and cannot be isolated.

Concurrency Control

Optimistic concurrency control (conflict detection):

    Any number of users can read the data

    The first user to commit the data will succeed and the others will fail

Pessimistic concurrency control (conflict prevention)

    Only one user can read the data at a time

    Reduces concurrency

Optimistic Offline Lock

Pessimistic Offline Lock

Preventing Inconsistent Reads

Pessimistic locks:

    to read data you need a read (or shared) lock; to write data you need to a write (or exclusive) lock. Many people can have read locks on the same time, but if anyone has a read lock nobody can get a write lock. Once someone has a write lock nobody can get a read lock.

Optimistic locks:

    use version numbers on the data. Only allow updates if the version numbers of the data are the same as when the data was read.

Deadlocks

Deadlocks occur when there is a cycle of write locks waiting on each other.

Deadlock detection

    pick a victim who has to throw away his work and his locks so that others can make progress.

Timeouts

    every lock has a time limit

    a user who hits the limit looses his locks and is essentially a victim

    long running sessions may loose locks even though there is no deadlock

Deadlock prevention

    force everyone acquire locks at the very beginning of their work and do not allow them to acquire new locks

    force an order on how everybody can get locks, e.g. alphabetically on product names

Application Server Concurrency

How does the server handle multiple requests concurrently and how does this affect the design of the application on the server?

process-per-session

    completely isolated

    resource intensive

process-per-request

    usually more active sessions at any one time than there are active requests

    used to reduce the number of processes, i.e. pooled processes handle requests over a large number of sessions

thread-per-request

    uses less resources

    less isolation between threads