ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Transparent Data Pipelines for JSP
Pages: 1, 2, 3

Exception Handling and Resource Reclamation

Facilities for exception handling in JSPs leave much to be desired. As I said, this is not a flaw of the JSP concept, but a problem of the current implementations. I am sure future releases of JSP will rectify this. In the meantime, there's no need to lose heart. There are some excellent solutions to circumvent the problem.

Why do we need exception handling on JSP pages? Although we are providing a nice, all-encompassing IDataSetNode object to the JSP, the navigation of this object might encounter exceptions, errors and runtime exceptions. And when an exception happens, the resources that you may have acquired will have to be returned.

Although it is possible to register error pages when an exception occurs, it has to be enforced on all of the JSPs, and programmers, as a rule, are a forgetful lot (if I am at all representative). The solution again lies in MVC. If there is a controller servlet that has transferred control to the JSP page, the controller servlet is a good place to perform this clean-up.

All that a controller servlet has to do is set up a CleanupRegistry in the HttpRequest (or more generally, the current thread) and let the model and the view register ICleanUpTasks with this registry. The controller servlet will call clean-up on this CleanupRegistry when the request returns from the JSP.

When using TDP, this cleanup registration typically happens in the model, and the clean-up in the controller and the view usually stays out of it. So the JSPs are completely exception-safe, as long as the JSP limits itself to accessing data from the passed hierarchical data set. Even in other cases, the JSP could always register a clean-up task if it were to request any clean-up as a post process.

Why are we going to such great lengths for cleaning up? How often do we run into this situation? Unfortunately, quite often, when we are dealing with relational databases and JDBC. Every time we access a result set we are dealing with three important resources:

  • ResultSets.
  • Statements.
  • Connections.

These resources will have to be either closed or returned to their pools once the data is collected from them. One cheap solution is to retrieve the result sets into vectors and close these resources at the data source level. This could be a bad idea for high-volume Web sites -- this would basically increase your memory trace, as you are commiting memory for all the rows at one time instead of processing them one at a time.

Processing one at a time is not that simple architecturally, because this processing takes place on the JSP, and the JSP is not good at cleanup. So the solution is to allow an abstraction like TDP and provide a close method on IDataSetNode, which will ripple through all of the inner relational data sets.

There is also something of a prevailing wisdom that one should not allow any exceptions to happen on a JSP page. The idea is that we can pre-collect all the data that a JSP page needs so that we can deal with exceptions before the JSP page is invoked. To me, this seems a tall compromise, in terms of scalability. In my view, one can minimize the exceptions that can happen on a JSP page, but one can never really stop runtime exceptions. I do agree that you have to minimize exceptions and find reasonable ways to deal with those severe exceptions.

This one single aspect of server-side programming, combined with connection pooling, determines how scalable and reliable your application server is.


TDP has much broader applications than the Web space. For instance, if one can standardize on the declarative definition of the compositional aspects of TDP, it is possible for multiple vendors to ship out-of-the-box TDP executors that one can plug into his or her applications, just the way they do now for JDBC drivers. And the programmers can be relieved from writing JDBC code, CICS code, etc., rather than focusing on the business logic that can manipulate the data returned.

As the data sets are already InfoSets, it makes lot of sense to return them in SOAP envelopes to make your backends SOAP-enabled, thereby serving your B2B and B2C needs simultaneously.

TDP will come in handy for enterprise reporting systems. Today, these reporting engines are constrained and pigeon-holed for a specific database and a specific kind of data source. Something like TDP will open up these reporting engines by infusing data in XML and let the reporting engines do what they do best, design GUI-based report templates.

The above analogy will apply to charting software as well. Let the charting engines design GUI templates for charts, and supply the needed data utilizing the declarative TDP. This approach has been successfully applied in the industry.

TDP is highly effective in bringing J2EE and XML to a much larger audience, allowing one to develop solutions in a much shorter timeframe, while maintaining the following characterestics:

  • Standards based: J2EE and XML.
  • Built-in architectural stability and scalability.
  • Highly maintainable.
  • Ability to use skillset diversity.

Satya Komatineni is the CTO at Indent, Inc. and the author of Aspire, an open source web development RAD tool for J2EE/XML.

Return to ONJava.com.