Changes Required for a Production Application

WebAuction is designed as a sample application. While it possesses the main components of a real-world production environment, it includes some simplifications.

Limiting Query Results

The WebAuction application uses simple entity bean finder methods to query the database. While these simple finders are acceptable in a prototype, they need refinement for a real application. For instance, the ItemBean includes a finder that returns all the items in a given category. On a real auction site, this could return hundreds—if not thousands—of rows. Obviously, a thousand items is too many to display on a Web page, and it is expensive to return this many items in a result set from the database.

A production application must limit the number of results returned by a finder. One common method is to include an additional condition in the finder clause that limits the query to a range of IDs. For instance, our finder could return all items in a given category with an ID between 100 and 200. The Web page would have a Next button to enable the user to ask for more results. The next page could run the query again, this time asking for IDs between 200 and 300.

Unique ID Generation

Many common business objects, including WebAuction's Items and Bids, have no natural “primary key” that would uniquely identify them in the database. Instead, a new primary key value is generated for every new item and bid. The only requirement is that primary key values be unique within the items or bids. WebAuction uses a separate IDGenerator stateless session bean to produce these unique IDs. Before an item or bid is created, the caller uses the IDGenerator's getNextValue() method to receive a new ID. The item or bid is then created with the generated ID.

The advantage of using a stateless session bean for unique ID generation is that the algorithm can be modified without affecting other code. WebAuction uses a database sequence value to generate unique IDs. While this scheme takes advantage of the database's existing ID generation support, it does involve an extra database round trip on each create to read the next sequence value. This is only acceptable if creates are relatively infrequent, but a successful production auction site will have frequent bidding.

There are several methods to increase the performance of the IDGeneratorBean and all evolve around limiting the number of trips to the database. A key point to note is that the Item and Bid objects require unique IDs, but there is no requirement that these keys be sequential.

A higher performance IDGeneratorBean could initially read the database sequence value to receive a new integer, but then hand out 1000 IDs based on that integer without returning to the database. For instance, the IDGeneratorBean might read the number “3” from the database sequence, and return the IDs 3000–3999 without returning to the database. Once the IDGeneratorBean has handed out ID 3999, it returns to the database sequence to get a new value. This scheme can support multiple concurrent IDGeneratorBean instances, each with its own 1000 ID range. This algorithm limits database access and improves performance.

Internationalizing WebAuction

Production Web sites must support multiple languages. While WebAuction includes only English language output, there is nothing to preclude internationalization. WebAuction facilitates internationalization by separating the presentation JSP pages from the presentation logic in JSP tag libraries. The WebAuction application could be internationalized by moving the printed messages from the JSP pages into separate message catalogs for each language. A user entering the internationalized WebAuction site could select a language, and the preference would be noted in the servlet session. The JSP pages would be reformatted to check the session for a language preference and access the appropriate message catalog.

Database Tuning

Nearly every e-commerce application uses a database for persistent data storage. One important aspect of improving e-commerce application performance is database tuning. WebAuction uses a simple database schema and queries. The database schema uses simple and portable data types, and tables are simple enough not to require database administration skills to understand.

However, production applications often require a database expert's skills. The database physical schema can be tuned to increase performance, for example, creating indexes to speed queries. A production application should also take advantage of the database's query optimizer and how it creates execution plans for the application's main operations. Sometimes a knowledgeable database administrator can make changes in the schema or queries that allow the optimizer to greatly improve performance. While database tuning is out of this book's scope, it should not be discounted when developing production sites.