CS636 Last class Practice final will be posted tomorrow.  On Friday, will post the music3 solution and the practice final solution.

Look at syllabus again: We have covered

We have studied one layered architecture the whole term and showed that it can handle both client-server and web environments, and as a plus, also web services (not officially covered, i.e., not on the final exam).

We push all the concurrency handling down to the database, and take full advantage of its ability to handle it. We have argued in detail that our code does not itself need explicit locks or semaphores, a great advantage. In practice, if you see a lot of locks or semaphores in use or proposed, think about putting the data in a database instead.

Recently we have covered its limits: really large sites, esp. in terms of multiple teams of developers, where microservices are now the preferred solution. But this is much harder to do. Use hardware first to stretch our simple solution.

Last week: example of timings for a busy web site, showing that concurrency in the database is much smaller than concurrency among user sessions in a web app.  In 1000 concurrent active user sessions, we found only 5 concurrent transactions at a time.  This is good news for anyone worried about overloading the database.  However, it shows what a challenge it is to properly test a webapp for concurrency problems. Most tests end up running without any transaction concurrency.

Here is a picture that tries to summarize the different time periods involved in web app execution:

request through layers

 Objects in the tomcat JVM for pizza3:

Since tomcat came up: DataSource, its Connection pool, containing live Connections for later use.

Longest lifetime app objects: created at first request to web app, live until tomcat brought down:

Intermediate lifetime app objects: session objects and things attached to them (session variables), last about 20 minutes after last request in that session. For pizza3, the StudentBean is attached as a session variable.

Short lifetime objects: everything associated with one request-response cycle, about 50 ms we hope.

Example of ordering pizza : two request cycles

So here the PizzaTopping objects, etc. have a lifetime inside the request cycle time.

The only domain objects that live longer are ones attached to the Session (none in pizza3, but user, cart, possibly product in music3)

Compare Client-server and Web Apps


Web App

One singleton graph per client, lifetime of app

One singleton graph for web app execution time

Single-threaded execution in Java code Multi-threaded execution in Java code, but argued that it's safe from race conditions.

One database holds all shared, changeable domain data—shared between clients

Same, though clients are now called web app users.

One JDBC Connection for app lifetime with plain JDBC, one Connection (inside em) for each txn for JPA implementation

One Connection (inside em) for each txn, in fact coming from a connection pool maintained by the DataSource.

Domain objects are short lived, with in-transaction lifetimes, with exceptions for some invariant objects and/or new objects


Stateless service layer, also DAO layer


Can have state in presentation layer, i.e., variables in the client app that save info from one action to another for a user.

Can have state in presentation layer, i.e., session variables that carry info from one request to another for a user.

 Book coverage for Final Exam

For pre-midterm, see notes17.html

Murach since midterm:

Chap. 5, servlets

Chap 6, JSP: can skip pp. 184-189 on topics only needed for Model 1 apps

Chap 7 Sessions to pg. 207, then can skip to pg. 224 and read to end of chapter (Download app)

Chap 8 EL to pg. 263

Chap 9 JSTL  to pg. 277, skip 278-279, read 280-285, skip 286-289, read 290-end of chapter (Cart app)

Chap 13 JPA  See JPA2Notes.html for notes on this chapter.

JPA Queries—just understand music2 examples.

Chap 22 as basis of Music project

Pg. 639: Domain class diagram doesn’t show id fields of domain classes, but they are in Murach’s domain classes. We have a Track class too.

Pg. 660 web.xml has security setup we didn’t cover

Pg. 663: DB diagram: we have track table too.

Pg. 664: SQL script is mysql-specific. We have a portable version.

Pg. 666-669: ProductDB class has static methods. Our ProductDAO has object methods, and is used to create a singleton object.

Chap. 23 Apps of the Music website: Shows the UI. We are using a simplified UI for user actions.

Homework since Midterm exam:

HW4: HTTP, JPA in pizza2, tomcat on topcat, JSP, servlets, tomcat at home
HW5: servlet1 in eclipse, ch07download, pizza3 in eclipse, compare pizza2 and pizza3, analyze session variable in pizza3.