db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: Occaisonal rollback on reboot
Date Fri, 02 Sep 2005 19:47:54 GMT
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
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.


View raw message