CS636 Last class

Practice final is posted.  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:  For non-JPA, replace "em" with Connection.

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. In music3, the User (represented by UserData) and Cart are session variables. They can be organized into a UserBean, as done in the music3 solution.

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 cart, possibly product in music3)

Compare Client-server and Web Apps

Client-server

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

Same

Stateless service layer, also DAO layer

Same

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. But not on final exam.

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: tomcat on topcat, JSP, servlets, tomcat at home, EMailList servlet, page flow for it
HW5: servlet1, errors, ch07download, pizza3 in eclipse, compare pizza1 and pizza3, analyze session variable in pizza3.

Look at practice final exam

Important Servlet Examples: parts of project, really

Servlet1: Servlet accepts request at its URL, outputs HTML directly, no forward

EMailList servlet: form submission to servlet, forward to "thanks" JSP page showing submitted data using EL. Page flow in hw4.

Cart servlet: one page showing list of products with "add" buttons, submits to servlet with productCode parameter, which sets up a cart session variable, then shows cart page with several buttons, discriminated by various action= parameter values. Submit goes back to the servlet, and the cart session variable tracks the current cart contents.  See page flow diagram in Chap 7 slides, linked at Nov. 7 class. Deployed on my tomcat.

Download servlet: First page shows list of albums (CDs), each with a link that carries a parameter for the product code. When the user clicks a link, the servlet checks if the user is already known (by cookie here), and is sent to the appropriate CD page if so, but if not, is sent to a registration page. After registration, the user is sent on the the chosen CD page.  To remember what CD the user was interested in, across the registration process, the servlet uses a session variable for the productCode. We haven't made a page flow for this.

pizza3: We have analyzed this to see that the room number is the one session variable here, in hw5. We made a page flow back in hw3.