Hell, yeah!
The example isn't even thread safe. A JDBC connection isn't fond of multiple, open Statements and there's no synchronisation. Unless the result set is being kept open for a reason, it and the statement has to be wrapped in a synchronized statement, where the data is dumped into some custom, data object. Only process data outside the critical section to reduce bottlenecks.
Or how about having HTML mixed up with Java. You can't show that to a web designer. If a web designer gives you a web page with the typical, artistic crap in it, it's painful to make a servlet emit it. And then someone will want the look and feel of the website completely changed. That's what JSP's for! A tutorial that teaches JSP but doesn't demonstrate it. Ummm...
If you're not going to learn an MVC framework like Struts, the servlet should extract the raw, data objects appropriate for a page from a core, business model then forward to a JSP page that formats them for display. Separating responsility means more maintainable code.
Following the tutorial means putting the hideousness of JDBC in every page controller. Separate this stuff into a core, business model, for the love of god!
And there's error trapping after writing part of the response, so it's too late to forward to a general error page with a contact 'phone number, apology or whatever. And if workflow has to be changed, such as mistyped data that must be corrected or a rejected transaction, the servlet is forced to emit the appropriate output for all eventualities, which is duplicated across many servlets. Rather than working out to which servlet to forward. Control logic comes before view logic.
I doubt I can give you some links as I now do the Struts-JBoss thing, which is a completely different brand of horror.
