> Well, while I was playing with it, I found a more serious issue:
>
> I've added close statements to my code, which is absolutely correct
> according to the API.
>
> The original code was this
>
> Statement st = conn.createStatement();
> ResultSet rs = st.executeQuery("select username

from test");

> rs.next();
> System.out.println(rs.getString(1));
> try {
> Thread.sleep(2000);
> }
> catch (Exception ee) {}
>
> and replaced with this:
>
> Statement st = conn.createStatement();
> ResultSet rs = st.executeQuery("select username

from test");

> rs.next();
> System.out.println(rs.getString(1));
> rs.close();
> st.close();
> try {
> Thread.sleep(2000);
> }
> catch (Exception ee) {}
>
> So when I run this new test and I connect to the test.gdb (I only
> connect, I do not issue any sql command) then the java test hangs
> up. It stops, but I don't know where. I've attached the log file,
> the jave test ran three iterations, so it read the first record
> three times.

Most likely this is a deadlock. I had similar problems in my code,
and the only thing that I needed was to set the transaction isolation
to TRANSACTION_READ_COMMITED. Current default transaction isolation
is TRANSACTION_REPEATABLE_READ.

> It hangs up at a op_response according to the log, but I can not
> interpret it.

Same was in my case. Look for a deadlock.

> Roman, I you tell me what would be required on a linux box for
> debugging, probably I could give an account. (although that linux
> box is not mine, but I will try everything to solve this)

No, I meant that I'm not able to do this on the weekend, since the
only computer here I have is my laptop running Win2k. I will try to
test it at work next week.

I will look into the code.

Best regards,
Roman