Archive for June, 2006

Best Practices – JDBC

Continuing from the previous entry, I’ll discuss JDBC. Although there was a section on Servlets, the recommendations are more decision-levels such as deciding on a framework, mad caching and hiring a UI designer. So here I go…

Use DataSource Whenever Possible

I don’t fully agree with this yet, since I still don’t see the absolute benefit when using the DataSource technique. The book explains that using the old Class.forName() and DriverManager.getConnection() contains references to specific implementation classes.

I don’t agree because these information are Strings, which can be read from a config file and drivers can be loaded dynamically. Java programmers have always also used generic JDBC interface to deal with the underlying database (as I mentioned in a previous post).Therefore I see the same level of portability in using both methods, especially when a ConnectionManager is used to retrieve connections (encapsulation of connection logic).

Pool Database Connections

Enough said. If you don’t understand this ask me or Google.

Separate Application, Persistence and JDBC logic.

As per most apps, beans are used to model entity information and are already separate from JDBC logic. As a plus, using a DAO interface model can further isolate your persistence logic from the application, allowing your underlying persistence implementation to switch to non-JDBC.

This is already a common pattern in EJB, where entity beans rely on a DAO to perform stores, loads and finds.

Do not Rely on Built-in Key Generation

For portability sake, this is a must. Besides difficulty in locating the record just inserted, other databases might not have this feature.

The book also provide a sequencing method to generate unique keys, though I think it can be more easily implemented with a SELECT MAX (only for trivial apps) or a separate table storing the current sequence. The method presented offers better performance than my methods, so do an evaluation before deciding which to use.

Use PreparedStatement

I would say not only use it, but use it correctly. The purpose of using PREPARED statements is that it can be executed repeatedly efficiently. Therefore if you prepare a statement, execute it once, and prepare the same statement again next time and execute it once, you aren’t really using PreparedStatement correctly.

The preferred way to use PreparedStatements is have it prepared once, and executed many times. Be it a static query or with ? parameters, these “prepared” statements will offer better performance.

Reference Columns By Number

This is actually two problems in one. The first is that access to metadata information is expensive, and referencing column by name requires metadata. Most programmers access columns by name now due to the flexibility and convenience of not needing to remember column numbers as well as able to change the sequence in the SELECT without affecting the code.

However, just like column numbers can change, column names can change as well when the SQL is changed. The book says that rs.getLong(1) is as bad as rs.getLong("personID")

The “correct” solution is to externalize both the SQL and the sequence number so that the query can be changed without affecting the code

new PreparedStatement(PERSON_QUERY);

Close Statements and ResultSets

Despit JDBC specifications, some drivers do not clean up as cleanly as specified. To clean up completely, use the finally clause. In fact, this template should always be used.

Connection conn = null;
PreparedStatement stmt = null;
ResultSet rs = null;
try {
conn = ..;
stmt = conn.prepareStatement(..);
rs = stmt.executeQuery();
while (
// ..
} catch (SQLException sqlE) {
// handle exception
} finally {
if (rs != null)
try { rs.close() } catch (SQLException sqlE) {}
if (stmt != null)
try { stmt.close() } catch (SQLException sqlE) {}
if (conn != null)
try { conn.close() } catch (SQLException sqlE) {}

Thread JDBC code in Swing Applications

In general I think this should be “Thread time-consuming task in GUI applications”. The threading, though it complicates the code, is necessary to provide a responsive GUI to the user. When time consuming tasks are performed in the GUI event thread, the event thread is unable to perform other tasks such as redrawing the UI or getting input from the user through the UI. This includes unable to cancel the event if the user chooses to.

At the same time, care should be taken when accessing GUI elements from threads. See the wiki for more information on this.

Do Not Use Primary Keys with Real-World Meaning

This tip effectively contradicts with the perfect data model of the primary key. The fact it is listed as a best practice in a published book demonstrates the vast difference between academic theory and industry practice. However for practical purposes, it is still better to issue a meaningless identifier to the data row.

You might argue some data like your IC number don’t change, but they might be entered incorrectly into the system in the first place (data entry, human/machine error) and needs to be modified.


Java Enterprise Best Practices – EJB

This book from O’Reilly provides “Expert Tips & Tricks for Java Enterprise Programmers”. Apart from pure EJB stuff, the book covers tips for servlets, JDBC, XML, etc. I’ll be wrapping up the tips in a few short notes, espcially those I’ve seen/read around. First I discuss EJB tips.

Use ValueObjects for bulk data transfer.

Instead of making a get call for each property in your remote object, use a session bean to grab all necessary properties in a single call (thus also using the session facade)

Handle Exception in EJB Code Correctly.

My opinion about this is you should handle exceptions correctly EVERYWHERE! This involves understanding of when to throw, catch or wrap an exception. For EJB the logic is:

RemoteException: declared on all remote interfaces exposed by EJB. Used to indicate a network problem. You should not throw it yourself. If you call another remote object and receive a remote exception, wrap it in an EJBException.

EJBException: Thrown by developer and caught by container. Indicates major error to signal container to perform a transactional rollback. Like a NullPointerException, it’s a runtime exception and should not be caught by a developer. A common use is wrapping SQLExceptions into EJBException.

Application-level Exception: Should be thrown/caught by developer as part of application logic. Must be serializable (the exception will travel across the network). Do remember Exception Basics: Don’t use exceptions to indicate normal flow.

Using Business Delegates for Clients

This may look like pure redundancy to new-to-EJB programmers, however this cleanly separates client logic and EJB logic. One way to see this problem is when importing EJB packages in servlet classes. If the back end changes to non-EJB or the front end changes to non-webbased you get a problem. By introducing another layer into the already-many-layers you improve scalability and maintainability of your application (theoratically).

Create a Build Environment.

Even if you have a fantastic IDE that can automatically do all these for you, it’s useful to be able to make small changes to your app and re-building it without firing up and twiddling with the (likely-heavy) IDE. This is even more useful if you really understand your deployment. (and useful for people to learn about the actual deployment)


Displaytag taglib

The displaytag library is a useful JSP taglib for generating html tables containing data in lists. By putting JavaBeans in an iterable list, the tag library can format the list into a HTML table, complete with the following features:

  • Mapping columns to bean properties
  • Built-in Pagination
  • Built-in Sorting
  • External sorting/pagination
  • I18n
  • Styles
  • Exporting to PDF/Excel
  • Integration with struts
  • Grouping (never tried)
  • Integration with webwork, sping framework (never tried)

Rating 4 out of 5. Excellent features, easy to use. 1 missing for un-organized documentation.


Apache Jakarta Struts (Action 1)

For the past two weeks I have actually been looking at a lot of Struts, but i’m still not well-versed enough to document it down, also because of the amount of information needed to document it. Seems like it’ll take a few pages.

Briefly going through it, Struts is a web application framework that enforces the MVC model. The sequence generally goes like this:

  1. The user makes a HTTP request through the web (e.g.
  2. The web server receives the request. By servlet mapping in web.xml, *.do requests are handled by the struts ActionServlet. The HTTP request is passed to the ActionServlet, which works as a controller dispatcher.
  3. The ActionServlet receives the request, and checks the name of the .do (Employee). It looks up the action mapping configured in struts-config.xml (or a corresponding module config file). Information regarding the action’s form bean, Action class, validation, mapping forwards are retrieved.
  4. The form bean declares the request parameters as Java data types, allowing automatic mapping to be performed, instead of retrieving all parameters as Strings.
  5. If validation is required, validation is performed based on the form bean types, and any validation.xml as configured in the Validator plug-in. The configuration file allows basic checking such as required fields, less-than/more-than, regex, as well as custom validation providers. If validation fails, the request is immediately forwarded to the validation failure page.
  6. Once validation passes, the Form Bean class is created and populated with the corresponding values in the request. The Action class is then called to perform business logic, using the information in the form bean class. The Action then redirects to the appropriate mapping forwards as defined in the action configuration.
  7. Control returns to the ActionServlet, which looks up the actual URL of the mapping forward in the config file. All these lookups allow complete separation of URLs between the view and model.
  8. The actual URL content is served to the client.

The framework is highly configurable, such as splitting the configuration into modules, using dynamic forms without creating actual form beans, tag libraries that easily display and retain information in form beans, etc.

Apart from Action 1, Struts also evolved into Action 2 and Shale Frameworks, which I’m unsure of the differences.

Comments (1)

Windows FileSharing ports

Windows shared folders uses NetBIOS over TCP/IP using these ports:

* UDP 137: NetBIOS name service
* UDP 138: NetBIOS datagram service
* TCP 139: NetBIOS session service

Need to try out if enabling these ports on a firewalled machine actually allows FileSharing.

[1] … 868,00.htm