SOEN 6011 Software Engineering Processes

1. SOEN 6011Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

2. Week 10 • Deliverable 3 • Concurrency • ACID • UnitOfWork • Identity Map • Lazy Loading

3. 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

4. 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

5. 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

6. Client, Web server, Db server

7. 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?

8. Concurrency Problems • “Essential problems”: • Lost updates • Inconsistent reads. • Another point of view: • Correctness • Liveness

9. Offline concurrency • “… the term we use is offline concurrency, that is, concurrency control for data that’s manipulated during multiple database transactions.”

10. Concurrency Control Two main approaches: • Optimistic concurrency control. • Pessimistic concurrency control. First let us examine the concept of transaction.

11. 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”

12. 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.

13. 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.

14. Optimistic Offline Lock

15. Pessimistic Offline Lock

16. Execution Contexts • Request • Session • Transaction • A transaction that spans multiple requests is terms a “long transaction”.

17. Some Basic Concepts related to WEA User Goals has issues performs

18. Can you see an advantage in using the Front Controller pattern?

19. Client, Web server, Db server

20. 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)

21. Where can this happen? In memory. “In” the database. Both of these places are subject to the problems of Inconsistent reads. Lost updates. Concurrent Data Manipulation

22. 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?

23. 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.

24. Data Source Patterns • Fowler: Chapter 10. • Data Mapper, TDG • Fowler, Chapter 11 • UnitOfWork • Identity Map • Lazy Loading

25. Unit of Work • Maintains 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

27. Identity Map • Ensures 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.

28. 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

29. Identity Map (p.195): Ex. Find Alice

30. 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. B A C*

31. 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).

32. Lazy Loading An object that does not contain all the data you need buts knows how to get it Eg, a customer with many orders, though generally you only want the customer name and address (for the request). Load orders only when required.

33. 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.

34. Proxy