Valentin Cozma wrote:
Stanley Bradbury wrote:
Not being a hardware or network guy I can't speak in detail to all
the TLAs you are using but do know the following is documented: Derby
database files must reside local to the machine hosting the Derby DBMS
engine. So that leaves out anything over TCP/IP and I know that NFS
mounts, Windows file shares and Samba mounts. These systems will
result in corruptions because there is not way to insure that a
physical write to disk was completed.
from what I know the problem is that nfs blocks and doesn't raise an
exception until SO tcp timeout is reached ( linux default 2 hours )
don't know about samba
With CIFS/SMB you issue SMB_COM_FLUSH to flush, and it's documented as
flushing to disk -- Samba can honor this (but the setting defaults to
off). Also, what you describe is NFS2 -- NFS3 can work asynchronously
if you want, but it can still operate in NFS2 mode as well.
So really, CIFS and NFS both appear to be okay for syncing -- NFS is
trickier to get working properly for locking, but that's another issue.
In any case, in my case the database has not been corrupted -- the
network went down, came back up, and Derby *thought* the database was
corrupted, but on forcing a shutdown and opening it again it worked.
So my original question stands but I'll rephrase it -- in this
situation, is there some way Derby can do this reconnection itself at
the store level, or is there some way it can do it at the Network Server
level, or do we have to shut down the entire Network Server and all its
embedded databases to do it at our own level?
Daniel
--
Daniel Noll Forensic and eDiscovery Software
Senior Developer The world's most advanced
Nuix email data analysis
http://nuix.com/ and eDiscovery software
