db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scotty Allen <li...@scottyallen.com>
Subject Re: Occaisonal rollback on reboot
Date Fri, 02 Sep 2005 06:17:09 GMT

Suresh Thalamati wrote:

> Yes.  log1.dat will contain the transaction log , that is used to  
> redo the transactions in case of a crash. So files in the log  
> directory are  essential to bring database to a consistent state  
> during the reboot after the crash and also for transaction  
> rollbacks ..etc.
> I wonder how log1.dat is missing , have not seen any bugs regarding  
> this. Some how the log  files are vanishing:
> 1) By chance , are the files in the database base log  directory  
> (<database-name>/log)  are compressed by some automatic/manual  
> process?

Nope, no compression here.  The volume is a normal OS X volume, and  
we're not doing anything special on program startup and shutdown.   
It's a plain vanilla derby setup.

> 2) is there some automatic mechanism  that is deleting the files in  
> the Users directory ?

Again, nothing special going on here.

> 3) Is some one manually deleting these files, thinking they are  
> just error log files ?

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.

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

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?

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.



View raw message