Category Archives: JavaRanch

Why JDBC + JSP = Bad

Posted on by
10

Over years of moderating at The JavaRanch, I’ve seen one type of question spring up on a weekly basis: that asked by people who need help with JDBC code inside of Java Server Pages (JSPs). As much as we may want to help this individual fix their particular problem, the overriding thought of “STOP WHAT YOU’RE DOING” often prevents us from doing so. The purpose of this post is to explain why putting JDBC code inside a JSP file is akin to shooting yourself in the foot. With a shotgun. While not wearing shoes.

Don't use JDBC inside of JSP pages

1. You cannot reuse the code
First and foremost is the issue of code reusability. While importing java classes is quite common, importing code from a JSP is not. While you can write JSP functions, although I never recommend doing so for reasons I won’t get into now, you’re basically writing code that you cannot be used anywhere else, particularly in non-JSP java classes. The most common counter response to this is “Well, I don’t need to use it anywhere else”. Yes, you do. Whether its just reusing code for making the connection to database or the code for performing a query and reading the results, it will be used again at some point in the future in a way you have not thought of yet. Unless you are being paid by the line and prefer this sort of thing, it’s a bad move, and I guarantee your code base will be much larger than someone who put all their JDBC code into normal Java classes. Larger code base means more difficulty to maintain and more headaches for you down the road.

2. You are mixing business logic with the presentation layer
Probably the most overlooked issue for inexperienced developers is the fact that you’re mixing the business/data layers with the presentation layer. I’ll put it another way, if your boss comes in one morning and says we’re throwing out the JSP front end and replacing it with a web service, Java Swing, Flash, or some other interface, there is virtually no way for you to reuse the database code without going through every line of every JSP file by hand. If the database code had been placed in plain java files, then you would have a path for packaging the JDBC code into a single JAR and making it available as a service to a different front-end client such as a web service, Flash, etc.

In enterprise development, the presentation JSP layer and the database are often separated by multiple layers of indirection such as described by the commonly used three-tier architecture pattern. Those who are just starting out programming often do not know why mixing these layers is bad, but I promise you if you stay with software development you’ll understand one day.

3. But it’s just this once!
Often times, JDBC code enters JSPs by developer lying to themselves saying “Well, it’s just this once” or “I just need to test something”. Instead of being removed when the developer is done ‘testing’, the code often persists for a long time afterward. Furthermore, putting your JDBC code inside of reusable Java classes makes testing go faster! Spending 10 minutes setting up a single reusable Java JDBC class will save you hours down the road. Then, if you want to test more than one JSP page with JDBC logic, you already have your Java class file to start with. Proponents of test-driven development tend to understand this better than anyone.

4. It’s really hard to maintain
Code maintenance is another topic that new developers do not fully appreciate since they have not spent years maintaining the same code base. Unless you write the most beautiful JDBC code imaginable, its very difficult to read through huge JSP files looking for bugs and/or making enhancements. It’s a lot easier if all the JDBC access is restricted to a set of files much smaller in size than the JSP code base.

5. It’s a really bad practice
If after reading this article you still do not fully understand why you should not put JDBC code inside of JSPs, let me simplify the issue by saying “Just Don’t Do It”. Whether or not developers understand the reasons against doing so is not as important as stopping them from doing so in the first place. In short, you create code someone else (possibly yourself) will have the misfortune of maintaining down the road.

javaranch’s forum migration – want to know more?

Posted on by
Reply

The JavaRanch Journal about the forum migration is out.

Since I was involved in the details of the project, I wrote quite a bit.  It contains:

  • My overview of why we did it, what technologies we used, the timeline and process
  • Pauline’s interview with Ulf, Ernest, Bear, Amit and myself
  • My article on the data migration including analysis.
  • A cute interview where Ernest talks in elvish along with a cute extended analogy he wrote comparing the forum migration to a physical farm move.
  • A Lucene article from the Lucene in Action authors.  (JForum uses Lucene making it relevant to the migration.)

javaranch/jforum – nailing down a threading problem

Posted on by
Reply

Similar to the thought process for debugging a performance problem, here’s one for debugging a threading issue:

  1. In Production, we have a problem where the threads in a forum listing disappear showing only one or two threads in their place.  We found a workaround pretty quickly (clear the cache), but want to stop the problem from occurring.
  2. For the better part of a week, we found it puzzling.  A couple moderators noted that the problem seemed to crop up after moving a thread from one forum to another.
  3. We still haven’t been able to reproduce the bug on demand.  It sounds like something threading related.  These tend to be the mysterious looking bugs.
  4. All right.  I’m going to sit down and look at the relevant code now.
    • I know the problem has something to do with the TopicRepository class which is where this data is stored.
    • I see clearCache method that empties the cache is in fact called when we move threads.
    • I also see addAll resets the forum list.  This seems to not be called since we only see a post or two.  Hmm.  Let’s see where this is called.  I see; it’s called when someone requests to view the list of topics in a forum.  The code gets the topics from the cache.  If there aren’t any topics cached or the cache reports as “not loaded” for the forum, it gets them from the database and loads the cache.  Clearly this isn’t happening.
    • I also see a method that adds a single topic to the cache.  It is called when we post announcements.  This looks promising.
    • I tried locally to reproduce the bug and got it!  We weren’t posting announcements though.  Then I searched the code for other calls to this method.  There is another call when we “update board status” which happens after someone replies to an existing thread.  Eureka!  This must be what’s happening.
  5. Now I can reproduce on our sandbox server on demand.  (see path below.)
  6. How to fix.  Well the topics being non-empty doesn’t seem like something I can control.  Looking at the other part – the loaded flag – seems more promising.
  7. I see the flag isn’t cleared in the clearCache method.  I’ll add that in and see what happens.
  8. The bug goes away!  Great news!

The path that causes the bug to manifest:

  1. open two threads in the Test Forum
  2. move a thread from Test Forum to Another Test – this clears the cache
  3. in Test Forum, add a post to an existing thread – this adds one topic to the the list
  4. reload list of threads for Test Forum – now it thinks there is one topic in the list and doesn’t look for more
  5. you only see the one edited thread in the list