Kathey Marsden wrote:
I am not very familiar with replication, but in the general case, this often happens because the copy is not done with the same operating system user as the subsequent boot or if the permissions are not preserved on the files. Even if the lck file is there, I think things should boot ok as long as the permissions for derby to remove the lck file are sufficient when Derby boots.
Same OS, same user, same perms. I think perhaps I don't have the connect parameters quite right - I was supplying a username/password as well as startSlave.
I'm now struggling with getting the slave to shut down cleanly, that goddam AntiGC thread refuses to die, sigh...
If I had one major criticism of Derby it would be of the admin areas - database & server startup/shutdown, and replication. Trying to get it to work reliably under SMF on Solaris is a royal pain.
-- Alan Burlison --
