>> 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

r> 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

r> 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.

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

Actually I don't much about difference between these, but it seems
soon I'll read as much as I can about it.

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

r> Same was in my case. Look for a deadlock.

Fine, but why? I understand if I update from isql at java at the same
time. But the java is reading only and in isql I do *nothing*, I just
typed "connect /opt/interbase/test.gdb;".

Moreover it works fine on Windows.

Daniel