• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Design Issue - querying DB from ActionClass

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been asked to contribute in solving a design problem and I want some informed opinions.

Scenario: We are creating a struts-based application with the following flow:

JSPs -> Struts ActionClass -> BusinessDelegate -> Session Fa�ade -> Pojo DAOs

Only one application server is envisaged.

Problem: For frequent query operations � like for fetching values that populate combos in every page in our application � will it be advisable to put the stored proc call in the ActionClass directly, or in the usual manner, traverse across the tiers to put the call in the DAO? If SP calls are executed directly from the Action class, will it speed up the application for frequently-required queries? In your opinion, how will this impact performance if in future the web and business tiers are separated onto 2 different appservers?

For mostly static data, what other options are available to avoid re-querying? Any suggestions will be appreciated. TIA.
 
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are two fallacies at work here:

  • That because logic is spread out over a number of objects, it will perform significantly worse than logic in a single object. This isn't true. Method calls are very fast, and do not significantly impact performance. Creating instances of objects takes a little longer, but this can be controlled by designing objects as singletons, caching them, etc.
  • That it's OK to sacrifice good design on the altar of improved performance. Even if a multi-tiered application did perform significantly worse than a single-tier application, I'd still opt for the multi-tiered application because it's a better design choice. A poorly designed application has costs that go well beyond performance costs.


  • This is not to say you shouldn't keep an eye on performance: just don't sacrifice good design for the sake of performance.

    In your opinion, how will this impact performance if in future the web and business tiers are separated onto 2 different appservers?

    Granted, it's going to take a little longer if you have to make a network call for your business methods. This can be minimized by using Transfer Objects, and other J2EE patterns. The most important concern is: do you really want some of your business logic in one tier and some of it in another?

    For mostly static data, what other options are available to avoid re-querying?



    One option is to cache this type of data in application scope using the ServletContext object. Data such as states, countries, colors, etc. are the same for all users, and they don't change very often. Query for them when the application first starts up and put them in application scope. This can significantly reduce calls to the database. The one drawback of this approach is that this data remains cached as long as the App Server is running. Even though the data changes infrequently, it does change sometimes. To get around this, you may want to set up a timed process that refreshes this data once a day or as often as necessary.
    [ April 30, 2006: Message edited by: Merrill Higginson ]
     
    Bring me the box labeled "thinking cap" ... and then read this tiny ad:
    Devious Experiments for a Truly Passive Greenhouse!
    https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
      Bookmark Topic Watch Topic
    • New Topic