Thanks Dag for taking the time to respond. See the following which occurred when trying to use FREEZE/UNFREEZE from a script using IJ:
and also here:
where Mike Matrigali commented:
Here is the documentation for using freeze/unfreeze to do a backup. The
expectation is that the freeze and unfreeze comes
from the same connection (or at least that is likely what is tested in derby).
I don't remember but think it might be likely that future connection requests
are stalled while a database is frozen, as part of work
necessary to keep a database in an ok state for a user backup routine to be
called. Logically you just need to stop writing transactions
but the implementation may just of have stall all connections.
Obviously this does not work well for the 3 separate script steps you describe,
but would be good to know if your use case works for
the intended use of freeze/unfreeze. And even if derby only supports same
and unfreeze, we should understand what is expected if the connection executing
the freeze fails or exits before doing unfreeze.
So from this, I still think it might be better to automatically unfreeze the database if a connection is lost. In the production environment it is quite possible that between the freeze and copy that all of the remaining connections available become used and blocked waiting for the database to unfreeze and if a failure occurs, there is now no way to unfreeze the database.
I have tried to use freeze/unfreeze from both a script and a utility application now to perform a backup as describe in the documentation, and both ways I have had something fail and being locked out and unable to invoke unfreeze.
On 10.09.2012 20:07, Bergquist, Brett wrote:
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.
Hmm. I just tried this, and found I can make another connection even when the database is frozen, although when I try to do an update the operation hangs as expected. Maybe there is a bug the prohibits a new connection in some (hitherto uncharacterized) cases?
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?