db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag Wanvik <dag.wan...@oracle.com>
Subject Re: Had a problem with SYSCS_FREEZE_DATABASE and am wondering is something can be done make this more robust
Date Tue, 11 Sep 2012 18:19:00 GMT

On 10.09.2012 20:07, Bergquist, Brett wrote:
> From the stack traces of the Derby engine, it appears that something 
> causes the utility to fail after the database was frozen and neither 
> the shutdown hook nor the try/finally unfroze the database.   So after 
> that point, the database was effectively locked up.   The system was 
> still operating and connections were being made trying to access the  
> database exhausting all of the connections.

So if none of your unfreeze attempt worked here, what happened to that 
process/VM? You say "failed", did it hang, did it complete normally, 
albeit with no effect, or was it killed off?
Curious, since If we were to implement an automatic unfreeze at 
connection close, if the method you used didn't work, an automatic 
unfreeze might fail too (if there is a bug in the code that prevents 
unfreeze from doing its thing). If it hangs without unfreezing it might 
be interesting to see the VM state at that point, e.g. via jstack.

> So I was thinking that maybe the database engine should have some sort 
> of protection if this were to happen.   Maybe the database engine 
> should automatically unfreeze the database if the connection that 
> freezes the database terminates/closes.   Or maybe a timer to be added 
> to the freeze command to automatically unfreeze the database after the 
> fact.
> I am thinking this because I was told on a previous emailing when 
> trying to build this utility totally from a script point of view using 
> IJ to freeze the database, SH to perform the ZFS snapshot and IJ to 
> unfreeze the database that it was not expected that the 
> freeze/unfreeze would be done from separate connections.  I fact I ran 
> into a problem with the utility at that point where the IJ connection 
> to unfreeze could not be created because the database was frozen.
> So I guess is there ever a use case that would require a database to 
> be frozen and not unfrozen before the connection is closed/lost?

View raw message