Alan Burlison <[email protected]> writes: > Dag H. Wanvik wrote: > >> I suspect that when you use the programmatic approach, the databases >> are not shut down cleanly. If the servers are started from the command >> line, I think the booted databases are shut down cleanly. >> >> Cf these lines in NotworkServerControlImpl.java: >> : >> // if the server is started from the command line, it should shutdown >> the >> // databases it has booted. >> private boolean shutdownDatabasesOnShutdown = false; >> >> This means that when the server is started via the API, each database >> needs to be shut down individually to get a clean shutdown (with >> checkpoint). > > Unfortunately I don't think that's workable in practice. Because > Derby auto-starts databases on connection, there is no way of stopping > clients opening the database again whilst the copy and child start is > happening. There needs to be some way to ensure the database is locked > and then to flush the log entries. Would a > SYSCS_UTIL.SYSCS_FREEZE_DATABASE followed by a > SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE do the trick?
No, I'm afraid not. SYSCS_FREEZE_DATABASE already performs a checkpoint. The problem is that the checkpoint is not allowed to remove the log generated by transactions that are still active. One solution could be to introduce a variant of freeze that fails if there are active transactions which have generated log records. Then you'd just have to retry until you can successfully freeze the database, but that could go on forever if new transactions keep coming in. Variants that block until the database is frozen (possibly also preventing new transactions from starting) or that abort other active transactions could perhaps also be used. Could the following be a practical workaround? 1. Add a replication user that's only used to start/stop replication 2. Temporarily disable all other users by unsetting derby.user.XXX 3. Perform clean shutdown of master database 4. Copy database and start slave 5. Start master 6. Re-enable the non-replication users This way I *think* you'd prevent others from booting the database while you're setting up replication. -- Knut Anders
