Re: Servlet problems

Nikola,

I hope that my comments will help. I included some code examples on what
to do and what will not work. Didn't you say you like the "Find the
differences" game? You have a good example of it below. Take your time
to read it, especially because I did not take a long time to write it
and there may even be errors in it. Sorry if there are some.

Good luck!

>>I'm afraid I don't speak JSP ;-) but I may suggest something.
>>
>
>The question is not really JSP related, I could test it in a Java standalone. I would hate to do so... I'm running low on time/nerves.
>
We all suffer from that :-(

>>Can you try to flush every output you send?
>>
>
>Perhaps... So, JSP would print as far as it goes and I will see where it crashes? Hmm, not bad. The other alternative I was thinking of was Log4J package to do some logging along the way.
>
Try logging on the web page itself. This will help you MATCH the log
messages to the web page output. It is dirty, ugly, and you must take
the debugging out for any production tests, but it helped me find really
ugly mistakes.

Something else tou may try is logging as much information as possible
about the state prior to an exception, in your catch blocks. Well, I
suppose you knew that already...

I am not sure whether Log4J is not a bit overkill for your present
problem, I never used it yet. Maybe System.err.println() is easier, but
that will probably be implementation-dependent.

>>For every println(), if you use them, just place a flush() immediately
>>after it. That WILL NOT solve your problem, and WILL degrade
>>performance, but MAY help you find the source for your trouble. Once
>>your problem is solved (I let you do the hard work), you can safely take
>>them away.
>>
>
>I'll try it.
>
>My dilema was whether JDBC calls were thread/recursion safe, I guess.
>
Stated that way, the answer is YES.

Supposing you will be using a single Connecion object, as soon as you
use different Statement objects for all your SELECT queries, which will
give you different ResultSet objects, it is thread/recursion safe.

*WHAT YOU SHOULD DO* :

Statement stmt1 = conn.createStatement();
ResultSet rs1 = stmt1.executeQuery(query1);
while(rs1.next()) {
Statement stmt2 = conn.createStatement();
ResultSet rs2 = stmt2.executeQuery(query2);
...
rs2.close();
stmt2.close();
}

*YOU MAY ALSO DO* :

Statement stmt1 = conn.createStatement();
Statement stmt2 = conn.createStatement();
ResultSet rs1 = stmt1.executeQuery(query1);
while(rs1.next()) {
ResultSet rs2 = stmt2.executeQuery(query2);
...
rs2.close();
}

*BUT YOU SHOULD NEVER TRY* :

Statement stmt1 = conn.createStatement();
ResultSet rs1 = stmt1.executeQuery(query1);
while(rs1.next()) {
rs1 = stmt1.executeQuery(query2);
...
rs1.close();
}

*THIS WILL NOT WORK EITHER* :

Statement stmt1 = conn.createStatement();
ResultSet rs1 = stmt1.executeQuery(query1);
while(rs1.next()) {
ResultSet rs2 = stmt1.executeQuery(query2);
...
rs2.close();
}

This last example will not work because stmt1.executeQuery(query2) WILL
IMPLICITLY CLOSE rs1.

In case you close a ResultSet implicitly, I strongly believe that the
data set is destroyed, and thus ResultSet.next() will throw a
NullPointerException.

This kind of problem is always hard to find. Do not despair...

Hope that helps,

Antonio Fiol
W3ping