So You Want to Practice your Code Reviewing Skills? - Summary

Earlier this week I published So You Want to Practice your Code Reviewing Skills? which challenged the readers to find bugs in ~ 150 LOC.


The replies were very interesting. Here's a summary

Concurrency/Distribution/Singleton

• instance() method is not synchronized
• sessionCounter needs to be volatile/guarded by synchronization (in visitorCount())
• (Mutable) Singeltons cannot be distributed. is If there is several instance of the webapp running, not all values will be counted because several counter will exist and not be synchronized from JVM to JVM.
• The singleton implementation is broken. See, for instance, this article.

General

• DataBaseHelperget() method may return the empty string ("") if no rows are in the table, and the singleton only expects a valid number or null, which will cause a NumberFormatException
• the counter may roll over. For a 7 year old web app this is perfectly possible.
• I consider constructs like this catch(Exception e) { sLogger.error("", e); } to be a bug.
  

JDBC

• The DB change isn't being committed so it has to rely on the underlying driver's behavior.
• The insert statement doesn't explicitly defines column names, which is susceptible to failure if the order of rows in the DB table changes.
• The update statement updates the row with param = 'SESSION_COUNT' although the insert inserts 'session_count'. Usually this would not work without special set-up in the db and/or connection.
• generateResult() does not close the ResultSet object. Note that the originating Statement object is hidden inside the DataBase.performSqlQuery() method (whose code is not given) so Statement also remains open. The closing of these two objects is deferred to the GC.
  

Final thoughts

• Do not use singletons. A singleton is a smell that indicates the need for dependency injection.
  
• In general, service objects in web-apps should not maintain state in (plain-old-Java) fields. If you need to have some state, write it to the DB. That's the only way to share state in a distributed settings.
• The nastiest bug of all: the combination of exceptions being silently absorbed, and DataBaseHelper.get() returning an empty string ("") leads to a situation where sessionCounter stays zero, which will reset the visitor count at the DB to 100, thereby loosing the (correct) visitor count.
  
  Here's the scenario: In generateResult() an SqlException if fired (let's say due to a temporary network problem). It is silently caught by generateResult() which then returns an empty list. get() will return an empty string, which will yield a NumberFormatException in reloadParamsFromDB(), which - again - is silently ignored.
  Therefore, no assignment to sessionCounter is taking place, so it retains its default value, zero. At the 100th call to addSession() sessionCounter current value (100) will be written to the DB.
  
  Solution: add to the value at the DB instead of writing to it.