Checking if a db is open without actually opening it

[Alan Burlison]

I'm wrapping the Derby replication stuff with some safety checks, and I
want to make sure that the slave DB isn't currently open before I
overwrite it.  Is there any way of asking Derby if it has a database
open without opening it as a result?

--
Alan Burlison
--

[Donald McLean-3]

The easiest thing would probably be to look for the lock file.

On Fri, Jul 3, 2009 at 1:41 PM, Alan Burlison<Alan.Burlison@...> wrote:
> I'm wrapping the Derby replication stuff with some safety checks, and I want
> to make sure that the slave DB isn't currently open before I overwrite it.
>  Is there any way of asking Derby if it has a database open without opening
> it as a result?
-------------------------------------------------------------
Family photographs are a critical legacy for
ourselves and our descendants. Protect that
legacy with a digital backup and recovery plan.

[Alan Burlison]

Donald McLean wrote:

> The easiest thing would probably be to look for the lock file.

Need to do it across the network, so that won't be easy.  Thanks for the
suggestion though!

--
Alan Burlison
--

[sridhar devatha]

hi donald mclean and alan burlison,

thank you for your help. may god do good to you all. whatever you said abt this error is correct. removing lock file helped me.
but. please anybody answer my remaining questions. it would be great help. I suggest adding these solutions to documentation files like getting started guide, reference manuals , developer guide will help reduce the mailing list traffic.

On Sat, Jul 4, 2009 at 12:52 PM, Alan Burlison <Alan.Burlison@...> wrote:

Donald McLean wrote:

The easiest thing would probably be to look for the lock file.

Need to do it across the network, so that won't be easy.  Thanks for the suggestion though!

--
Alan Burlison
--

--

Yours Sincerely,
Devatha Sridhar

[Kathey Marsden]

sridhar devatha wrote:
> whatever you said abt this error is correct. removing lock file helped me.
Please never remove the lock file or any file under the database
directory manually.  Removing the lock file will allow dual boot which
will corrupt your database.


Kathey

[Alan Burlison]

Kathey Marsden wrote:

> Please never remove the lock file or any file under the database
> directory manually.  Removing the lock file will allow dual boot which
> will corrupt your database.

On a slightly related note, I'm struggling to get replication to work,
getting an error when I start up the slave:

DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: Cannot start
replication slave mode for database 'opensolaris'. The database has
already been booted. [XRE09]

It hasn't - I started the slave with no database directory at all, so
there is no way it could be locked.  I think this error is because I'm
copying everything under the database directory from the master to the
slave, and that includes the lock files.  The replication documents just
say to freeze the master and then 'Copy the database to the slave
location', I think they need to be more explicit about exactly what
files need to be copied from the master to the slave.

--
Alan Burlison
--

[Kathey Marsden]

Alan Burlison wrote:

>
> On a slightly related note, I'm struggling to get replication to work,
> getting an error when I start up the slave:
>
> DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE09, SQLERRMC: Cannot start
> replication slave mode for database 'opensolaris'. The database has
> already been booted. [XRE09]
>
> It hasn't - I started the slave with no database directory at all, so
> there is no way it could be locked.  I think this error is because I'm
> copying everything under the database directory from the master to the
> slave, and that includes the lock files.  The replication documents
> just say to freeze the master and then 'Copy the database to the slave
> location', I think they need to be more explicit about exactly what
> files need to be copied from the master to the slave.
>

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.

Kathey

[Alan Burlison]

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