[Logo]
Forums Register Login
mvc - jsp:useBean, run DAO lookup only once?
I have a jsp that uses jsp:useBean. Shown here.


I have controller code that is as follows:


This code works. However, every time I load my jsp page, the data population of the dropdown is kicked off, and the backend data retrieval takes over 6 seconds. I would like to know what I need to change to only do the lookup once, then re-use the results for everyone who uses the application.

I tried using the context, but this.getContext returns null.



If the data only needs to be read once, and is not user-specific, establish a context listener to read the data and place it in application context (the ServletContext).

It is then available to all resources, including servlets and JSPs.
I tried that. Let me try again, and get the error message. Thanks for your response!
So just addingone line of code to my controller results in an exception.
Line of code is ...

this.getServletContext

I originally had code to try to store the productFamilyList as an application variable, and was getting the exception also.



Your servlet is not really a servlet. It should contain an implementation of doGet() or doPost() (depending on which HTTP method will be used to access it). You cannot just add random methods to a servlet and expect it to magically act as if a request is under way.

It looks as though your class should not be extending HttpServlet, as it is a bean, and not a servlet.

Why are you calling it from the JSP in the first place, and why the is the useBean declaration there? It's rarely needed when using EL and JSTL.
My DAO class retrieves lookup values which populate the product family lookup in my jsp. I am trying to figure out how to only retrieve the data once, and store same, so that the next person who kicks off the jsp doesn't have to wait for the DAO to retrieve data a second time...
I already answered that:

establish a context listener to read the data and place it in application context (the ServletContext).


A context listener's init method will be called once at app startup.

Once the list is in the app context, the forEach can access it directly.
SOmething like this, for example? Just dont' want to head off in a completely wrong direction -- well, besides the one I initially .. headed .. off .. into. :banghead:

That's more like it.

"foo" will be available throughout the web app.

By the way, you can use an empty implementation of the destroy method. There is no need to remove the scoped variable when the app is shutting down. The whole app is about to be bazookaed, so there's no need for the superfluous code.
P.S. Don't forget to configure the listener in the deployment descriptor.
P.P.S. Why the unnecessary try/catch?
Cool, Cool, Cool, Cool!

try catch in the listener class?
 

stephenr davidson wrote:try catch in the listener class?


Yeah. Why is it there?

Superfluous code is bad code.



That's an old saying that I just made up.
No idea. It is sample code that I will build my code from.
:-)
OK, don't use sample code from that source again. There is no need to try/catch there, and just doing a println and dismissing the exception is a really bad idea.
Ok. Here is MY modified code.
And it works, as I can see the output from my DAO. Now I need to figure out how to get to it in my foreach loop.

Faricken Awesome!


 

stephenr davidson wrote:Ok. Here is MY modified code.


Here are some questions for you to answer about that code:
  • Why the constructor?
  • If the data lookup fails, what's your intended strategy? (Hint: simply printing out the stack trace is not a good one.)
  • Have you considered using real logging rather than System.out?

  • Now I need to figure out how to get to it in my foreach loop.


    Easy: items="${productFamilyList}" [edit: ah, I see you figured it out]
    Why the constructor? What I read indicated the need for an empty constructor.
    Exception handling? What is your definitive guide to this? Do you have one that you consider golden?
    Yes, I will use real logging. :-)
     

    stephenr davidson wrote:Why the constructor? What I read indicated the need for an empty constructor.


    Nope. If you don't have anything concrete to do in a constructor, don't include one. A nullary constructor that does nothing will automatically be created. Again, the principle here is to not explicitly include any superfluous code.

    There does need to be a constructor that accept no arguments, but you do not need to supply it unless you are going to do something in it. (And in all my years of doing this, I can think of nothing useful to do in such a constructor.)

    Exception handling? What is your definitive guide to this? Do you have one that you consider golden?


    There is, of course, no one rule that governs every situation.

    Think of this particular situation and answer: What happens if an exception is thrown? What is the effect on your application? What do the users experience?


    This thread has been viewed 1604 times.

    All times above are in ranch (not your local) time.
    The current ranch time is
    Sep 25, 2018 04:55:58.