Today's concept: we judge it mainly by running it.

Drill
-Create two client windows on the database
-Edit in a cell
-Add rows
-Delete rows
-Notice that the data file on disk is different
-Try adding a bunch of rows (so it scrolls offscreen) then edit it. Make sure that the other window does not have row onscreen when editing.

Functionality grading (85 points)
Can see data from server in table (things start up OK) 20
25 Edit cell: updates in editing client properly 15, updates in second client 10. Update requires clicking to see -5.
15 Add row: updates in editing client properly 5, updates in second client 10. Update requires scrolling/clicking to see -5. If last test fails, -5.
20 Delete row: updates in editing client properly 5, updates in second client 10, cache invalidated correctly (just removing one row from cache doesn't work right since later rows change index) 5. Update requires clicking to see it -5 (cap -10 for these errors).
File written to disk 5

Code (15 points)
-TMServer should spawn a thread for each notification to improve responsiveness (7 points) Some people used SwingUtilities.invokeLater here, which actually ends up serializing the update notifications. -3 if sendToAll joins the threads (not efficient and should not be needed) .
-TMClient should implement a cache (8 points) -5 if the cache is not lazy (copies over everything on startup or on updates) -NOTE:Points not subtracted for non-lazy caching (updates only) since it is not clear in handout to implement as such. -3 doesn't add data to cache on miss in getValueAt. cache clears on updates (other than delete row) -3. NOTE: The client should actually put the GUI update notifications in invokeLater. See the announcement from 6/5.