The County - Developer's Site

Home

Architecture

Database

JoCC Paper

Lilac Docs

Manage Test Server

NSF Stuff

Technical
Standards

Tools

Prototype

Old Papers

Old Prototypes

Technical Standards

It will help to have some technical standards for the project. Here are some thoughts. They are divided into sections.

Web Application

Parameters

Parameters for the application (like the name of the JDBC driver class) will be stored in the application's web.xml, like this:

<context-param>
<param-name>test_param</param-name>
<param-value>test</param-value>
<description>A test parameter</description>
</context-param>

You can access parameters via a ServletContext object, like this:

public class show_app_param extends HttpServlet {
        ...
        String param_value = "<empty>";
        ...
        param_value =
            this.getServletContext().getInitParameter("test_param");
            out.println("<h1>Parameter value:" + param_value + "</h1>\n");

You can run this code at https://lilac.sba.oakland.edu/test/servlet/show_app_param. 

Database

Naming Conventions

All objects have lower-case names.

Plurals are avoided. So a table would be called "person" and not "people."

Id fields as x_id, where x is some identifier.

Types

Primary keys are mostly INTEGER UNSIGNED AUTO_INCREMENT.

Pooling

Database connection pooling speeds things up significantly. We'll use the Protomatter classes. See the Tools page for more information. 

Prepared Statements

Prepared statements should be used where appropriate for efficiency. Constants should be used for placeholders. For example:

PreparedStatement updateSales = con.prepareStatement(
    "UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ?");
updateSales.setInt(1, 75);

should be:

PreparedStatement updateSales = con.prepareStatement(
    "UPDATE COFFEES SET SALES = ? WHERE COF_NAME LIKE ?");
updateSales.setInt(COFFEE_SALES, 75);

Particularly common prepared statement objects can be cached in application variables.

Transactions

Consider using transactions for groups of updates. If you set autocommit to false, set it back to true after completing the transaction.

Exceptions

We should handle SQLException and SQLWarning objects in some standard way.

 

Java Language

There are some standards for variable naming, class naming, method naming, etc., from Sun. You can download a PDF here. Should we follow them?

Efficiency

We should pay attention to obvious time and memory hogs. For instance:

while (rs.next())
	{
	String n = rs.getString("name");
	out.println(name);
	}

creates unnecessary String objects, slowing execution and using memory until the garbage collector runs. It could be:

String n;
while (rs.next())
	{
	n = rs.getString("name");
	out.println(name);
	}

We can gather tips as we progress.

In general, it's faster to use the append method of StringBuffer than the + operator of String, since the former does not create unnecessary objects.

Packages

All the Java will be in a package called thecounty. We could created a package thecounty.base for base features, and packages like thecounty.worksheet and thecounty.stories for classes that implement specific tasks. Things like document note and village maintenance classes would be part of thecounty.base. We should talk about this idea.

Exceptions

We should create an exception class hierarchy of some type, though I'm not sure what yet.

We should standardize the way we log exceptions. For instance, we might have a debug flag that, when true, directs exception messages to the HTTTP stream (so they appear on a browser screen). When false, they are written to a log file only.

We need to decide on the location and format of exception log file(s).

Servlet/JSP Issues

Threading

JSPs and servlets should be thread-safe. Remember that there could be multiple threads of the same JSP running at once. This means:

• Using objects instead of instance variables in JSPs
• Synchronizing access to shared objects

Synchronizing should be done carefully, since it can degrade performance and introduce deadlocks. Synchronized code should short and fast. We should track of all sections of synchronized code to make deadlock prediction easier.

Synchronizing Application Variables

Here is some code showing a good way to check for the existence of a shared application-level variable, and set it:

// See if the object is already in the application
String storeMe = (String)
  application.getAttribute("StoreMe");
if (storeMe == null)
  {
  // If the object is null, it must be created
  synchronized (application)
    {
    // Check again to make sure only one thread
    // performs the create
    if (application.getAttribute("StoreMe") == null)
      {
        application.setAttribute("StoreMe", "stored");
      }
    }
  }

Synchronization is a relatively expensive operation. This approach only does it when required. 

Precompiling JSPs

We should tell Tomcat to precompile JSPs when we have made a bunch o' changes, so we can check for compilation errors all at the same time. (KRM: There is an app for this in a book I have - I'll try to get it running.)

Caching and Buffering

Commonly-used values should be cached to avoid unnecessary processing. For instance, the user's name should be cached in a session variable.

Contact Kieran Mathieson (mathieso@oakland.edu) with questions or comments.