Scotty Allen wrote:
Suresh Thalamati wrote:
<snip ..>
Nope, these errors are from my personal laptop, and I haven't touched
any of the files in the data directories. I did run a test whereby I
killed the java process that was running the application, and then
deleted log1.dat manually, and verified that this did result in the
rollback behavior we're seeing, so that's consistent.
1) When you see the error(System may be in a inconsistent state,
missing file /Users/scotty/k2db-data/k2db/pkb/log/log1.dat). Does
the file log1.dat exists ?
2) What are the files on the log directory before you boot the database ?
3) are there any others in the derby.log ?. Set the property
derby.stream.error.logSeverityLevel=0 in the derby.properties ,
the properties will make sure all the errors are written to the
derby.log(http://db.apache.org/derby/docs/10.0/manuals/tuning/perf90.html).
could you please post to the list, the derby.log from the start of
the application.
Try running the application on different disk/location and check if
you are missing committed transactions, there also.
Yep, I'll definitely run some more test on other platforms, as well as
other OS X machines/environments.
That would be great. This issue is really puzzling me!
I wonder if this has something to do with the rws/rwd issues on OS X,
mentioned in the bug DERBY-1 (http://issues.apache.org/jira/browse/
DERBY-1). Does someone know more about this bug, and whether there
might be a possibility these issues are related?
If you have not set fileSyncTransactionLog flag database creation
would have failed. One case I am not sure is what errors you will get
if this flag is not set on all the boots. This flag should be set for
all the database boots, Derby System does not make this property
persistent. Best place is to set it is in the derby.properties file.
Also, should we be doing anything special on program shutdown to try
and minimize issues like this? I've seen a connection flag to tell the
database to shutdown, but it's not clear if this is actually
recommended, or only needed if you have a need to explicitly close a
database programatically.
Shutting down the database is always a good idea if you can, it
decreases the time to boot the database
next time. Current problem should never occur, even if the datbase is
NOT shutdown.
Thanks
-suresht
