SOEN 6011Software Engineering Processes
Section SS Fall 2007
Dr Greg Butlerhttp://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html
Week 10• Deliverable 3
• Concurrency– ACID
• UnitOfWork
• Identity Map
• Lazy Loading
Deliverable 3
• Read Java threads tutorial (if necessary)– You need thread-safe Java code
• Do SOEN 344 Tutorials 3 and 4– UnitOfWork– Identity Map, Lazy Loading
Deliverable 3
• Everyone use same players, either– Alice– Bob
• Allow your players to play multiple games at the same time from separate browsers
• Store statistics in DB
• Decide whether to store Game state in DB
Deliverable 3 – Fowler Session State Patterns
• Problem: where to store session state
• Client session state– “stateless” server stores state on the client
• Server session state– Keep state on server in serialized form
• Database session state– Store state as committed data in DB
Client, Web server, Db server
Deliverable 3
• Should your code affect anyone elses?
• … or their database content?
• … or their serialized session state?
• … or their client-side stored session state?
• … or your other client-side stored session state?
Concurrency Problems
• “Essential problems”:– Lost updates– Inconsistent reads.
• Another point of view:– Correctness– Liveness
Offline concurrency
• “… the term we use is offline concurrency, that is, concurrency control for data that’s manipulated during multiple database transactions.”
Concurrency Control
Two main approaches:
• Optimistic concurrency control.
• Pessimistic concurrency control.
First let us examine the concept of transaction.
Transaction• Key concept for handling concurrency issues.• 2 or more parties dialog / exchange messages.
• A transaction:– Well defined start and end.– Overall system and resources are in a consistent
state at start and end of transaction.– “All or nothing”
We want transactions to be A.C.I.D.
• Atomic.– For a transaction to succeed all of its steps must
succeed.– “All or nothing”
• Consistent– A system’s resources must be in a consistent state at the
start and the end of the transaction.
• Isolated– Effects of a trans. must be invisible to other open trans.’s
until it is committed successfully.
• Durable:– Results of committed trans should be permanent.
Concurrency Control (Fowler Ch 16)• Optimistic concurrency control:
– Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction.
• Pessimistic concurrency control– Prevents conflicts between concurrent
business transactions by allowing only one business transaction at a time to access the data.
Eg, file locking on most OS’s.
Optimistic Offline
Lock
Pessimistic Offline Lock
Execution Contexts
• Request
• Session
• Transaction– A transaction that spans multiple requests is
terms a “long transaction”.
Some Basic Concepts related to WEA User Goals
performs
issues
has
Can you see an advantage in using the Front Controller pattern?
Client, Web server, Db server
Concurrency: Strategies
• Avoid it if you can.
• Use reference implementations: e.g. DBMS.
• Understand the issues and limit:– Number of threads.– Data sharing (our focus)
Concurrent Data Manipulation
• Where can this happen?– In memory.– “In” the database.
• Both of these places are subject to the problems of– Inconsistent reads.– Lost updates.
Application DBMS
Database Management Systems (DBMS)
• Well developed (tried-and-true) technology.
• Hence we will try to push the concurrency down into the DBMS as much as possible.
What does this suggest about your choice of Session State Pattern?
Design solutions regarding “in memory” data sharing …
• Java: “synchronize” primitive can sometimes be used:– E.g. a Singleton’s getUniqueInstance() is
declared as synchronized. (What could happen if it wasn’t?)
• Careful choice of– Declaration and use of static fields.– Object instantiation.– Java’s ThreadLocal.
Data Source Patterns
• Fowler: Chapter 10.– Data Mapper, TDG
• Fowler, Chapter 11– UnitOfWork– Identity Map– Lazy Loading
Unit of WorkMaintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems
• Caches DB access
• Minimizes (slow) DB calls
• After commit UoW alters DB
Client
Movie
DB Unit of Work
New Movie
select
register clean
change title
register dirty
commit
save
update
Identity MapEnsures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them.
Example:Data Mapper &
Identity Map
Problem: Each person has many buddy’s (also Person objects) so may load many copies of the same object
Solution: Identity Map
Person
PersonMapper
PersonTDG
Identity Map (p.195): Ex. Find Alice
A Problem of O/R Mappings
• When are objects loaded, saved and changes committed?– Load A first.– Load B first, then A– Load B, then A,
change B, …
• O/R = object / relational• Fowler calls this a “behavioral” problem.
A
B
C*
A Solution: Lazy Loading
• Comes under various forms.– Virtual Proxy
• This is particularly useful for large compound objects where only some of the data may be needed (for the request).
Lazy Loading
An object that does not contain all the data you need buts knows how to get itEg, a customer with many orders, though generally you only want
the customer name and address (for the request).
Load orders only when required.
Virtual Proxy
• Extract an interface from Person.
• Result: <<interface>> IPerson.
• Create PersonProxy– One one field (the primary key): name.– When another field value is requested, it
fetches the real person from the DB and then returns the value by delegation.
– On subsequent calls, it simply delegates.
Proxy
-name-age
Person
-name
PersonProxy
«interface»IPerson
0..1
-buddy
0..1