db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Rauscher <ralph.rausc...@blue-elephant-systems.com>
Subject Empty tables returned in the second connection to the Derby network server (Derby
Date Sat, 06 Apr 2013 10:01:33 GMT
 I'm seeing a strage behaviour which I seem to cannot get a hold of. I have the problem that
sometimes when I do a select on a table, that table is reported as being empty (empty result
set) although it definitely contains data.
 What I'm doing is I'm starting a Derby network server within one program, doing some selects,
inserts, etc. in that program and it works perfectly. 
 I then try to access the same database from another Java program. And here it depends.
 If I use a debugger and set a breakpoint in the server program during startup, right after
the database has been created and the program obtained a connection to it, then the client
program will work (can do selects without problems and getting data from the tables).
 I disconnect the client program and let the server program continue (removing the breakpoint
in the debugger). The server program will internally do some selects, updates, etc.
 If I later reconnect the same, previously working client and try to do a select on the same
table as previously, that table is reported as completely empty (empty result set although
it definitely contains some data). To verify, if I reattach the debugger to the server program
and execute the same select with server program's connection to the database the very same
table is full of data.
 What could be the cause of this? Is this a setup or locking issue?
 Best Regards
    PS: I also tried a more complex setup again setting a breakpoint in the server program
right after it has creates the DB and connected to it. I then start the first client. The
first client can successfully see data in the table. I let the server progrm continue (which
will do some selects, updates, etc.). The first client can still see all data. I then connect
a second client (with the first one still connected) and try to do a select: table is emtpy.
Doing the very same select in the first client program will return data just fine. Looks like
the time the client connection to the Derby database is made determines whether the client
can see data in some tables or it cannot. Interestingly system tables will always return data
in all clients no matter when they connected.

View raw message