Three-tier architecture

Three-tier architecture Presentation Service Layer Business Logic Domain Model Data source

Concurrency • Often in service layer • Keep domain model independent of technology • Keep presentation layer simple • “On-line” locking is when a business transaction is the same as a database transaction. The DBMS handles these. • Concurrency makes life difficult • “On-line” locking is less difficult

Concurrency problem • Airline reservation system • Tell customer whether there are seats available at a certain price • If customer agrees, reserve a seat. • Stupid problem - give two customer the same seat • Unavoidable problem - inform customer that seat has already been taken

Reserving a seat price = flight.lowestPrice(); … Transaction = session.beginTransaction(); if (flight.lowestPrice() >= price) flight.reserveAt(price); else … transaction.commit();

Facts of concurrency control • Committing a transaction can fail • Failure is normal in concurrent systems • Should test failure case

When you need offline concurrency patterns • When application spans several systems • And don’t want to use a “transaction monitor” • When application closes session but does not discard data

Concurrency Patterns • Optimistic Offline Lock • Use timestamp to abort a process if another process interfered with it • Pessimistic Offline Lock • Use lock to keep other processes from accessing data • Coarse-Grained Lock • Use a single lock for a set of related objects. • Implicit Lock • Allow framework to acquire the locks

Pessimistic Locking • “Real” locking. • Three step process • Lock all data you read and write • Make changes • Unlock data • Can fail because of deadlock • Never fails after work is done • Less concurrent than optimistic locking

Optimistic “locking” • Optimistic concurrency control is not locking • Keep version number (time-stamp) on all data • To commit a transaction, check that all data has the right version number, then update. • Transaction commitment can fail • Works well when chance of two transactions changing the same data is small

Service Layer • Service layer (and domain model) is often developed by more technical programmers. • Applications are usually developed by programmers who do not understand concurrency well • So, make the service layer responsible for concurrency control. • But sometimes concurrency control is hard to separate from presentation.

Course-Grained Locking • Instead of locking each object individually, have a single lock for a set of objects. • Example: When editing an expense report, lock the entire report. • Prevents two people from editing the same report • Very simple

Fowler’s First Law of Distributed Object Design • Don’t distribute your objects • First, distribute presentation layer. Next, distribute data source. As a last resort, distribute domain layer.

Myth of Distribution and Objects • In OOP, objects will “send messages” to each other. • Thus, it is easy to build distributed systems from objects. • Just build a normal OO system • Decide which objects run on which machine • Use proxies to talk to remote objects

Sad Reality • Good OO design is usually not a good distributed design • Fine grained objects cause performance problems • Reliability – operations can fail • Synchronization – more concurrency

What to do? • Divide system into subsystems • Represent each subsystem with a “remote façade” • Ensure that data that is passed to and from a remote façade is a “data transfer object” and not a pointer to a real object

Remote Facade • Fine grained objects are the right answer for complex logic. • Coarse-grained objects are the right answer for distributed systems. • Remote Façade puts a “thin skin” on a group of fine-grained objects to make it be a single large object.

Three-tier architecture Presentation Remote Facade Service Layer Business Logic Domain Model Data source

Data Transfer Object • To avoid multiple calls to a Remote Façade, put all the data needed in one object. • DTO is the collection of data needed by a call. • Think of DTO as “encapsulated XML” • Normally a DTO is bad object design, but it is necessary for distributed systems

Subsystems • Eric Evans says to divide a domain if several groups of people work on it or if group gets too large • Divide domain if parts are on different servers

Subsystem • Divide a system into parts if different groups work on them or they get too large. Put the parts on different servers if necessary. • Each part has a façade. If necessary, make it a remote façade.

Three-tier architecture